Residual #14: obtain exact ~330 LOC repro + Windows ETW/-Z time-passes deep-dive

[hyperpolymath]

Carved out of #14 (subtleties: tracked items 1 & 2) so #14 can close on its answered question.

What remains, and why it can't be a code PR

#14 conclusively showed the 16–32 GiB OOM is not checker algorithmic complexity (linear on Linux and the windows-latest CI leg; reconstructed ~330 LOC scaffold checks in ~1.5 MB). Two of #14's original tracked items are inherently not closable from this environment:

1. The exact ~330 LOC repro file. It was never attached to Type-checker OOM (16-32 GB allocation) on deeply-nested str_concat / format chains #1/Type-checker root-cause investigation: reproduce the 16–32 GiB allocation observed on Windows in #1 #14; only its owner has it. We have a faithful reconstruction (crates/my-lang/tests/fixtures/issue_14_scaffold.my), but not the original.
2. A bespoke Windows ETW / -Z time-passes allocator deep-dive on stable-x86_64-pc-windows-msvc, Windows 11. Requires the original file and a Windows host with nightly tooling — neither is available in the Linux CI/dev environment.

These are not defects to fix in code; they're artifact/host-dependent forensics. They are now permanently guarded by the checker-scaling.yml Windows matrix leg + the dhat profile artifact, so any regression toward the pathological regime fails CI with concrete numbers rather than depending on a one-off manual report.

Definition of done (owner action)

• Attach the original ~330 LOC file to this issue (or confirm it's unrecoverable).
• If recoverable: run it on the original Windows toolchain under heaptrack/dhat/ETW + -Z time-passes; compare to the Linux/Windows-CI figures.
• If unrecoverable: close as "cannot reproduce; superseded by the permanent CI guard."

Leading non-checker hypotheses to check if the file resurfaces: recursive-descent parser stack/recovery allocation, recursive AST Drop (see the sibling Drop issue), or a debug-vs-release / debug-info / span-table difference on the original toolchain.