fix(scripts): accept CRLF tar listings in check-package

[MFA-G]

Summary

sdk/typescript/scripts/check-package.mjs rejects a valid npm tarball when the local tar emits CRLF line endings for tar -tvzf, as reported in #32.

The non-regular entry check ran a multiline regular expression directly over the raw listing:

if (/^[^d-]/mu.test(listing)) {
  throw new Error(
    "npm tarball contains a non-regular entry (symbolic or hard link, device, or pipe).",
  );
}

In JavaScript both CR and LF are line terminators for multiline anchors, so ^ matches between the CR and the LF. The following \n is then tested as if it were the first character of a new line, it is neither d nor -, and a tarball containing only regular files and directories is reported as containing a link, device, or pipe.

The check immediately below already normalized the very same output with split(/\r?\n/u), so the two validations disagreed about what a line is.

Changes

• Add sdk/typescript/scripts/tar-listing.mjs with two small helpers: tarListingLines() normalizes a tar -tv listing to entry lines (LF or CRLF), and hasOnlyRegularEntries() checks the entry-type column of already-split lines.
• Use them in check-package.mjs so entry types are inspected per line instead of via a multiline regex over the raw output. entries now reuses tarListingLines() rather than repeating the same split expression.
• Add sdk/typescript/tests-ts/tar-listing.test.ts covering LF and CRLF listings, unterminated and empty listings, and rejection of symbolic links, hard links, devices, and pipes under both line endings.

Behavior is unchanged for LF listings, and genuinely non-regular entries are still rejected — the symbolic-link, hard-link, device, and pipe cases are asserted with CRLF as well as LF, so the fix cannot silently weaken the check.

Testing

Run from sdk/typescript on Linux (Node.js 22.23.2, pnpm 11.9.0, bun 1.3.14):

• bun test tests-ts/tar-listing.test.ts — 8 pass, 0 fail.
• pnpm run types — passes.
• pnpm run format — "All matched files use Prettier code style!".
• pnpm run build && pnpm pack then node scripts/check-package.mjs ../../dist/<tarball>.tgz — every tar listing and entry-type check passes. The run then stops in the later installed-package smoke step, because installing the packed tarball resolves an upstream dependency version that is not published to the registry from this environment (ETARGET ... @openai/codex@<alpha>). That failure is unrelated to this change and reproduces on an unmodified checkout.

I confirmed the fix addresses the reported cause rather than the symptom, by exercising the old and new logic against the same fixtures:

OLD accepts CRLF regular-only listing? false
OLD accepts LF   regular-only listing? true
NEW accepts CRLF regular-only listing? true
NEW accepts LF   regular-only listing? true

I do not have a Windows machine available, so the CRLF path is covered by the fixtures above rather than by a real CRLF-emitting tar.

Risk and rollout

Low. The change is confined to a build-time packaging validation script; no runtime or published SDK code is touched. It makes the check accept listings it should always have accepted, and adds no new dependency.

Public disclosure review

• No customer, partner, prospect, or user identities, data, or identifying details are included.
• No credentials, personal data, private source, scan findings, or nonpublic links or tickets are included.
• I reviewed the branch name, title, description, commits, changes, comments, logs, screenshots, attachments, and links for public disclosure.

Fixes #32