fix(ts): match union diagnostic order across skipLibCheck modes

Related #960, #973, #974, #846, #66.

A matched TypeScript 5.7.3 control shows that the displayed order of an admitted JavaScript union depends on skipLibCheck, even with identical source and lib: ["es2023"]:

/** @type {ReadonlyArray<number[] | string[]>} */
export const nested = [[1], ["x"]];

import { nested } from "./owner.js";
const wrong: number[] = nested[0];

With allowJs, strict, and noEmit, tsc reports Type 'string[] | number[]' is not assignable to type 'number[]'. when skipLibCheck is false. With only skipLibCheck: true changed, it reports Type 'number[] | string[]' .... Both reports then give the same nested string[] and string failures. The #973/#974 fixture uses the default skipLibCheck: false; Home currently prints number[] | string[] in that fixture.

TypeScript's union construction sorts by the runtime IDs of the constituent types (getUnionTypeWorker / addTypesToUnion in TypeScript 5.7.3), whose allocation order is affected by library checking. Home's interner sorts by its own TypeIds and its diagnostic renderer sorts display entries again. The exact construction-order difference needs tracing; changing a fixture or special-casing display text would mask it.

Acceptance: pin both skipLibCheck settings with exact TypeScript 5.7.3 CLI streams, match the import diagnostic in Home while preserving the incompatible-member chain, and pass the expanded stream audit plus relevant checker/Program/LSP suites under the memory guard.

TypeScript 5.7.3 compiler-API confirmation with identical owner.js, main.ts, lib: ["es2023"], allowJs, strict, and noEmit: after getSemanticDiagnostics(), the source union constituents are [string[] id 98, number[] id 315] with skipLibCheck: false, versus [number[] id 86, string[] id 87] with skipLibCheck: true. The diagnostic text follows those member IDs. This rules out the earlier flat() hypothesis; the difference is in type allocation during library checking. The Home CLI currently prints number[] | string[] under both modes.

The new #973 flat.ts fixture is now on main in b214ad08c. With the checker fix in 4be9ed980, all five diagnostic sites and nested explanations match TypeScript 5.7.3 in both checkJs modes. The exact-stream audit is 153/155; both remaining differences are this issue: TypeScript prints string[] | number[] for the imported source union at flat.ts(5,7), while Home prints number[] | string[]. No other stream changed. The issue stays open.

Pushed 78932e2 to main as Glenn with two exact-control configs for flat.ts: skipLibCheck=true in both checkJs modes. Under a 768 MB guard, TypeScript 5.7.3 reports number[] | string[] in the imported union for each new config, while the existing skipLibCheck=false config reports string[] | number[]. The existing home-tsc binary happened to match the new controls, but it predates the latest check.zig source; the full oracle auditor refused it, correctly. A guarded home-tsc rebuild and full exact-stream audit are pending the >=40% host-memory gate. The underlying union allocation/display-order fix remains open.

Further TypeScript 5.7.3 checker evidence from the same flat.ts project: after getSemanticDiagnostics(), skipLibCheck=false yields string[] id 98, number[] id 315, union id 3598 (display string[] | number[]); skipLibCheck=true yields number[] id 96, string[] id 98, union id 99 (display number[] | string[]). Calling getTypeAtLocation before semantic diagnostics misleadingly produced number[] | string[] in both modes, so diagnostic/checking order is causally relevant. The #975 fix needs to preserve the checker allocation/provenance behavior; a display-text special case would be wrong.