[api-extractor] Upgrade bundled TypeScript to 6.0.x

[hl662]

Summary

Upgrades @microsoft/api-extractor's bundled TypeScript compiler from 5.9.3 to 6.0.3 (the latest stable 6.0.x).

api-extractor bundles a pinned compiler because it relies on undocumented compiler internals, so the bundled version has to be advanced and re-validated deliberately on each release rather than floated.

I noticed #5793 made an attempt to bump to TS 6.0.x, but it ran into CI problems. The newer compiler reports the grammar error TS1540 for the legacy module Foo {} namespace keyword. playwright-core's protocol.d.ts used that keyword through 1.56.1, and because api-extractor treats compiler warnings as errors in production mode, this failed the build of this repo's own @rushstack/playwright-browser-tunnel.

Playwright fixed this in 1.58 (microsoft/playwright#38558), so this PR also bumps the repo's pinned Playwright to 1.58.2.

@modelcontextprotocol/sdk@1.10.2 exposes its subpath types via exports["./*"] with no "types" condition, so under the 6.0 compiler's new default (moduleResolution: bundler) they no longer resolve. Node10 restores the resolution rushstack's mcp-server already compiles under.

@modelcontextprotocol/sdk@1.29.0 adds the missing "types" condition, so the pin can go away once mcp-server moves to it — but that should probably be done under a separate issue/PR (I tried triaging locally, its types are now built against zod 4 and this repo's mcp-server uses zod 3)

Bumping the compiler surfaced a second, smaller compatibility issue. TS 6.0 also flips the default CommonJS moduleResolution from node10 to bundler, and under bundler api-extractor's analysis can't resolve @modelcontextprotocol/sdk's subpath-export types (they lack a types condition), so @rushstack/mcp-server's production build fails with a TS2307 flood. I tried bumping the SDK first, but the only release with fixed exports (1.29) drags in a zod 3→4 migration — too much for this PR — so I pinned moduleResolution: node10 for mcp-server, which is the resolution it already compiles under.

I was looking ahead towards TS 7, and knowing that api-extractor uses some compiler internals, I assume there are regression concerns, since the newer compiler likely won't be at feature parity with the current one. So I also added a test file for TypeScriptInternals, and noticed there was dead code in there.

getDiagnosticsProducingTypeChecker was removed from the compiler in 4.7 (the dual type-checker was unified into getTypeChecker); the existing ?? getTypeChecker fallback already handled it, so I've consolidated the code path to just be getTypeChecker. Wrote a test case for this in a new TypeScriptInternals.test.ts, that can be expanded ahead of TS 7 to cover the other internal methods, if you think that's worthwhile.

Refs #5052, #5319. Supersedes #5793.

Let me know if the testing justification above is out of scope or warrants a separate PR, or if you would prefer to take the PR over instead. I can help deliver this PR to the finish line with comments and reviews

Details

The change is split into three commits:

1. Upgrade the bundled compiler (+ a small cleanup):

• Pinned typescript to 6.0.3 in apps/api-extractor/package.json; added 6.0.3 to the typescript allowed-alternatives in common-versions.json (kept 5.9.3, still required by the published @microsoft/api-extractor pulled in transitively); regenerated the lockfiles / repo-state.json.
• Validated each (ts as any) internals shim in TypeScriptInternals.ts against the v6.0.3 source, refreshed the source-pointer comments, and removed the dead getDiagnosticsProducingTypeChecker branch (see Summary). Other shims are unchanged.
• Added the first unit test for TypeScriptInternals (pins the getTypeChecker → getEmitResolver → hasGlobalName chain).

2. Bump Playwright to 1.58.2 (for TS 6.0 compatibility):

• Upgraded playwright, playwright-core, and @playwright/test from 1.56.1 to 1.58.2 in playwright-browser-tunnel and the playwright-local-browser-server VS Code extension, picking up fix: address TypeScript 6.0 deprecations playwright#38558 which converts protocol.d.ts from the legacy module keyword to namespace. Without it, api-extractor's analysis of the tunnel emits the TS1540 flood and fails the production build under the new compiler.

3. Pin moduleResolution: node10 for @rushstack/mcp-server (for TS 6.0 compatibility):

• TS 6.0 changes the default CommonJS moduleResolution to bundler, under which api-extractor's analysis can't resolve @modelcontextprotocol/sdk@1.10.2's subpath-export types (no types condition) → TS2307. Pinning node10 in mcp-server's tsconfig.json — the resolution it already compiles under via the repo toolchain — realigns the analysis with the build. No change to the published package.

How it was tested

All results below are from local runs on my Mac, running Node 24.14.0; CI will re-verify.

• rush rebuild --to @microsoft/api-extractor builds clean against the 6.0 typings; rush test --to @microsoft/api-extractor passes (80 tests, incl. the new TypeScriptInternals test).
• Reproduced the failure and confirmed the fix: rush rebuild --to @rushstack/playwright-browser-tunnel --production (the mode CI uses) failed on the TypeScript bump alone with 126 TS1540 diagnostics from playwright-core@1.56.1/protocol.d.ts; after bumping Playwright to 1.58.2 it builds clean (0 TS1540). The playwright-local-browser-server extension also builds clean under --production.
• mcp-server: rush rebuild --to @rushstack/mcp-server --production failed with TS2307 on @modelcontextprotocol/sdk under the bump; with the node10 pin it builds clean (0 TS2307, no deprecation warning, no golden change).
• api-extractor build-test etc/ snapshots are unchanged.
• Full-repo rush rebuild --production (matching CI's mode): the only failure is localization-plugin-test-03 (build), which is unrelated to this change — untouched by this PR, builds with the repo toolchain TypeScript, and present on main (it reproduces only on my machine; main's CI is green).

Impacted documentation

None.

[hl662]

@microsoft-github-policy-service agree