Fix spurious TDZ when a for-header reads a name the loop body shadows

[svenrog]

Summary

Fix spurious TDZ when a for-header reads a name the loop body shadows

Details

Loop-body lexical flattening (#2610) folds an eligible body block's let/const
bindings into the pooled loop environment. The eligibility gate (NamesOverlap)
only checked body names against the header's declared names — it missed the case
where a body name shadows an outer binding that a header expression references:

for (let l = r; l < o; l++) { let r = e[l], o = t.get(r); ... }

Here r/o in the header resolve to outer bindings, but flattening folded the
body's r/o slots into the loop env, so the header read them while still
uninitialized → ReferenceError: r has not been initialized. V8/SpiderMonkey/JSC
run it fine. This is the exact shape in Turbopack's module-factory runtime, so it
aborted rendering of Turbopack/Next.js bundles. The bug fires from the test and
update positions too, not just init.

Fix: add HeaderReferencesAnyBodyName, declining to flatten when any body slot
name appears as an identifier in the init/test/update. It over-approximates in the
safe direction (a matching property name or nested-scope declaration only forgoes
the optimization), mirroring EnvironmentEscapeAstVisitor.ClosureReferencesAny.
The scan runs once at statement construction, so there is no per-iteration cost,
and flattening still applies to loops whose headers reference no shadowed name.

Regression introduced in 4.12.0 (#2610); worked in 4.11.0.

Linked issue

Fixes #2708

Test plan

• Added or updated unit tests in Jint.Tests (LoopBodyFlatteningTests: init/test/update header refs + a reduced Turbopack module-factory shape)
• Ran dotnet test --configuration Release locally (3629 net10.0 / 3566 net472, 0 failures)
• For ECMAScript spec changes: ran Jint.Tests.Test262 and confirmed no regressions (99431 pass, 0 fail, 135 skip)
• For interop changes: covered in Jint.Tests/Runtime/Interop — n/a
• For perf changes: included before/after numbers from Jint.Benchmark — n/a (narrows an existing optimization; construction-time guard only)

Breaking change?

No.

[lahma]

Thank you!