perf(ts): bound virtual-file conformance program execution

Observed problem

At main 1b07917, the exact TypeScript conformance test with HOME_TS_CONFORMANCE_START=0 and HOME_TS_CONFORMANCE_LIMIT=1 passes 1/1 on pinned Zig 0.17 and Zig 0.18, but the cached 0.17 test execution takes about two minutes for the single ts-expect-error-js fixture. The next window, START=1 LIMIT=1, reached a 240-second wall bound on 0.17 without a terminal aggregate. Both runs used run_bounded, HOME_RUN_MAX_MB=3840, and -j1; the timeout is not a passing result. The passing case peaked at 352 MB of process-tree footprint, so memory exhaustion was not the observed cause.

The fixture has one virtual JS file and no import graph. After #841 corrected mixed-case @fileName parsing, it correctly routes through runProgram and matches the exact upstream diagnostic. The program path is therefore necessary to investigate; returning to the old concatenated-source path would reintroduce the filename defect and is not an acceptable fix.

Work to do

• Profile the stages of runProgram and ts_program.loadImportClosure on this pinned fixture, using guarded serial runs.
• Remove redundant work or improve the underlying compiler/library/graph operation without skipping checks, replacing results, or weakening exact baseline comparisons.
• Verify the same pinned exact fixture remains 1/1 on both Zig versions, establish a repeatable timing comparison, and retry START=1 LIMIT=1 under the 3840 MB cap.
• Keep #841 and #832 informed. Full-corpus parity remains tracked by #66.

Evidence: docs/docs/bun-port-evidence/2026-10-17-ts-virtual-filename-case/README.md. The previous START=0 LIMIT=5 attempt timed out at 240 seconds and must not be credited.

Guarded source-level sample update (2026-10-17): the cached Zig 0.17 exact START=0 LIMIT=1 executable completed 1/1, peak tree footprint 349 MB. I sampled the live test process twice for five seconds, around 14 seconds and later in the run. Both samples were entirely under runProgram -> Program.loadImportClosure -> Program.compileAll -> checkPreparedSource -> Checker.checkSourceFile, with substantial stacks in checkInterfaceDecl -> lowererLowerWithTypeParams -> substituteType. The first sample had 854/854 main-thread samples inside this chain; the later sample had 848/848. This is evidence of declaration semantic-check CPU work, not baseline I/O or a memory runaway. Related generic-substitution/declaration-policy work is already tracked in #842. No checks or baselines were bypassed. The START=1 LIMIT=1 240-second timeout remains unmeasured.

Current-main guarded recheck at 8a07cb3 after the joined-resolution-path cycle fix: the unchanged exact conformance window HOME_TS_CONFORMANCE_FULL=1 HOME_TS_CONFORMANCE_EXACT=1 HOME_TS_CONFORMANCE_START=1 HOME_TS_CONFORMANCE_LIMIT=1, using zig build test -j1 -Dfilter=ts_conformance -Dts-conformance-test-filter='opt-in full', exceeded the 300-second run_bounded wall limit (exit 124) under HOME_RUN_MAX_MB=3840. No aggregate or passing result was emitted. This is 60 seconds beyond the earlier 240-second timeout, so the path-normalization fix did not by itself resolve #908. No fixture/compiler edits or pass claim; next step is stage-level profiling of runProgram/loadImportClosure with the same guard.

Follow-up stage diagnosis on current main 8a07cb3: direct execution of the freshly compiled, filtered conformance test identifies the exact START=1/LIMIT=1 fixture as upstream directives/multiline.tsx (two virtual files, including /.lib/react.d.ts). The direct unchanged fixture still exceeded 75s and 115s guarded bounds. A five-second macOS sample of the live guarded process (PID 43959, physical footprint 98.8 MB at sample) recorded 3,594/3,594 main-thread samples under runProgram -> Program.loadImportClosureImpl -> Program.compileAll; 1,622 samples were under Checker.checkInterfaceDecl, with 1,059 under lowererLowerWithTypeParamsInner and 735 under substituteTypeUncached in one branch. This is evidence of checker CPU work during React declaration processing, not proof that any specific memo/cache change is safe. The earlier 300s Zig-build timeout is now known to reach the test executable: --verbose showed the cached 30 MB test artifact launching, and direct execution printed the fixture name before stalling. No source/fixture edit or passing result is claimed. The sample is retained locally at /tmp/test_2026-10-19_192700_CL3Y.sample.txt; next step is attribution to a concrete interface/substitution environment and a semantics-preserving cache or algorithm fix, then exact negative/positive conformance gates.

Temporary, reverted checker instrumentation narrowed the hot work further: on the exact multiline.tsx fixture, a guarded 55-second run entered the bundled DOM Document interface without finishing; a later 85-second run advanced through many Document interface members, reaching HIR byte offset 615817 before timeout. This is broad expensive member lowering, not evidence that one member loops forever. Both diagnostic patches were removed with a zero source diff afterward; no performance fix or exact-case pass is claimed. The five-second CPU sample in the prior comment remains the stronger stage evidence. We should profile substitution reuse across Document member signatures and preserve full readonly/generic semantics rather than skipping library checks or adding a fixture-specific cutoff.

Current-main retry on 8325f77, pinned Zig 0.17, one process under HOME_RUN_MAX_MB=3840: HOME_TS_CONFORMANCE_FULL=1 START=1 LIMIT=1 TRACE=1 with the single opt-in survey test filter reached the unchanged 240-second wall bound (exit 124) without a fixture RUN trace or aggregate. The expected installed ts-conformance-tests artifact is absent, so this attempt cannot distinguish test-binary compilation from fixture execution and earns no passing/timing credit. No source or fixture was changed; no parallel heavy jobs or raised memory ceiling. Next qualification should build the filtered test binary separately under the guard, then time the exact fixture from that verified binary.

Follow-up diagnosis on current main 8325f77 under one 3,840 MB guarded process at a time: building the filtered conformance test binary separately succeeded 3/3 (cached), then direct execution of START=1 LIMIT=1 identified fixture multiline and independently timed out at the original 240-second wall bound. Temporary env-gated stage probes (fully removed afterward; git diff clean) showed virtual-file setup, bundled/test-library mounting, type expansion and preloads all finish. Program import-closure bind/scan fixpoint reached 2 -> 8 -> 19 -> 21 files, then entered the final semantic check. Per-file markers reached provider /.typescript/lib/lib.dom.d.ts and did not leave that provider before a separate 75-second guarded trace bound. This is a concrete final-check/library hotpath lead, not proof that lib.dom alone accounts for the entire 240 seconds; no fixture result, skipped check, timing win, or source fix is claimed. The earlier 240-second build-wrapper timeout is now classified by the direct-binary run as a real fixture execution stall, not merely compilation. Next work: profile compileFileWithTypedGlobals/checker on the unmodified lib.dom provider, then improve the actual algorithm and rerun both START=0 and START=1 exact controls.