Reduce stripped ESM module load latency

[noise64]

Why

The refreshed TypeScript latency matrix on the consolidated npm-loader stack showed a separate ESM bottleneck: loading 64 KiB of whitespace-preserving strip output took roughly 11 seconds on both P2 and P3, while the same input completed inline in about 200 ms.

A five-sample phase experiment attributed essentially the entire delay to two repository-owned Rust scanners stepping byte by byte through stripped whitespace. QuickJS declaration, filesystem resolution, evaluation, and the unresolved residual were sub-millisecond.

What changed

• bulk-skip contiguous ASCII whitespace in the two CJS-global ESM scanners
• bypass import.meta.main rewriting when the source contains no import token
• add a dense-whitespace semantic regression
• add a reproducible exact-revision P2/P3 phase-attribution experiment
• refresh the full P2/P3 strip/transform latency matrix

No runtime state, cache lifetime, filesystem invalidation, public API, or generated type changes.

Results

Target	Phase baseline	Phase candidate	Reduction	Full-matrix prepared ESM
P2	10,657.94 ms	192.28 ms	98.20%	190.68 ms
P3	11,058.54 ms	197.36 ms	98.22%	188.89 ms

The final raw P2/P3 phase pair is retained. Baseline attribution remains summarized in Markdown, and the full four-report latency matrix records the end-to-end result.

Validation

• phase report contract: pass
• TypeScript latency report contract and exact currentness: pass
• P2 module-resolution runtime suite: 48 passed
• P3 module-resolution runtime suite: 48 passed
• cargo build --all-targets: pass
• cargo clippy --all-targets -- -Dwarnings: pass
• full P2/P3 skeleton Clippy feature matrix: pass
• Rust formatting, tool Prettier/ESLint/TypeScript checks: pass
• independent frozen-diff review: pass

Stack

Draft stacked on #154 (bench/npm-metadata-baseline). Review this PR after the consolidated npm-loader baseline/cache PR.