Fix #435, #669, #625, #641: arrow/closure capture in generator & async-arrow state machines

[nickna]

Compiled-mode arrows that capture variables inside generator and async-arrow state machines were miscompiled. Each issue's primary case is now fixed and passes --verify; deeper sub-cases fail-fast with a clear compile error (never a silent miscompile) and are tracked by follow-up issues.

What & why

#435 / #669 — arrows inside sync generator bodies

• Collection gap: CollectArrowsFromExpr had no Expr.Yield case, so an arrow inside a yielded expression (yield arr.map(x => …)) was never registered → the callback compiled to ldnull → "Array.prototype.map callback is not callable". Added the case.
• Capturing arrows: GeneratorMoveNextEmitter is the only emitter that uses the base ExpressionEmitterBase.EmitArrowFunction, so I taught the base to build the display class for capturing arrows via the existing GetThisField / GetHoistedVariableField hooks. This fixes read / loop-var / this captures without adding a 4th per-emitter duplicate (it actually reduces the triple-sync surface).
• this capture: GeneratorStateAnalyzer.UsesThis didn't descend into arrows, so this used only inside an arrow left the receiver field (<>4__this) undefined → NRE. Fixed with a focused sub-visitor.
• Write-captures (forEach(n => s += n)) need a function display class the generator SM lacks → clear compile error, tracked by Compiled: arrow inside a generator body that writes a captured variable needs a function-level display class (mutation lost) #674.

#625 — async arrow writing a captured variable emitted unverifiable IL (StackUnexpected)

A boxed value-type state machine cannot be verifiably mutated in place — unbox yields a readonly (controlled-mutability) managed pointer, so stfld through it fails ILVerify and can drop the write in complex state machines. Fix promotes direct-child written captures into the reference-type function display class; the arrow reads/writes outer.functionDC.field (a class reference → verifiable). Async-method and top-level-arrow variants → #682.

#641 — capturing async arrow nested in a top-level async arrow was unsupported

Threads the single capture through the standalone stub's $TSFunction "target" prepend slot, loaded from the enclosing arrow's frame. Standalone captures are resolved in the emitter at low priority (below module globals) so a top-level variable a standalone arrow closes over still reads live from its static field rather than the by-value snapshot. Write-back and multi-capture → #684.

Verification

Check	Result
Full xUnit suite	12,713 / 12,713
TypeScriptConformance	31 / 31 (no type-checker code changed)
New regression tests	29 (generator arrow bodies, async captured writes, nested async captures)
--verify on every repro	passes
Test262 corpus	could not run here — pre-existing 0x80131506 test-host crash (crashes before executing any test; independent of these compiled-only changes)

A mid-work regression (6 *_CapturedTopLevel_AsyncArrow tests) was caught and fixed: the standalone-capture read had to move to low priority in the emitter, since a top-level var is also registered as a standalone capture but must read live from its static field.

ILVerifier now surfaces the failing IL offset / found / expected in its error messages (it previously reported only "Unexpected type on the stack" with no location) — this is what made #625 diagnosable.

Reviewer notes

• Scope discipline: each issue's headline repro is fully fixed; the harder sub-cases (generator write-capture, async-method/top-level Compiled: async arrow that writes to a captured variable emits invalid IL (StackUnexpected) #625 variants, nested write-back/multi-capture) require larger shared-storage infrastructure and are deferred with clear compile errors + tracking issues (Compiled: arrow inside a generator body that writes a captured variable needs a function-level display class (mutation lost) #674, Compiled: async arrow writing a captured var is unverifiable inside an async CLASS METHOD or a top-level async arrow (same root cause as #625) #682, Compiled: nested standalone async arrow captures — multi-capture and write-back unsupported (follow-up to #641) #684) so nothing silently miscompiles.
• Also filed Type checker: spreading a generator METHOD's result is rejected (return type inferred as '<inferred>', not iterable) #687 — an unrelated type-checker gap (spreading a generator method's result) found while smoke-testing.
• Rebase before merge: origin/main advanced ~6 commits during development (adjacent async-generator try/catch + for-await rework). No file-level conflicts (they touch sibling partial files), and Compiler: array methods with arrow/function callbacks inside a (sync) generator body are not callable #435/Compiled generator body: arrow functions are miscompiled (map/forEach callback not callable; captured closures crash) #669 remain unaddressed there — but please rebase and re-run the suite before merging since that work is nearby.