Compiled: static async generators (#778), class-expression generators (#765), computed symbol-method binding & class-expr symbol methods (#755 s1/s2)

[nickna]

Completes three compiled-mode generator/symbol-method gaps. All four fixes route through the existing state-machine / symbol-registry infrastructure (no new machinery), are IL-verified, and run identically in both back ends.

Fixes #778 — compiled static async *m()

EmitStaticMethodBody routed a static async *m() into the plain-async branch, so its yield hit "Yield not supported in this context". (The sync static *m() was already handled by #692.) EmitAsyncGeneratorMethodBody is generalized with an isInstanceMethod flag plus a new static stub (EmitAsyncGeneratorStaticStubMethod, no this, params from arg 0, value-types boxed) — mirroring the sync static generator. EmitStaticMethodBody now dispatches static async *m() there first (it has both flags). The generator default-parameter prologue from #737 applies for free.

Fixes #765 — compiled generator methods in a class expression

const C = class { *gen() { yield … } } was emitted on the linear path (→ "Yield not supported"). The class-expression emitters now (a) give generator/async-generator methods the right return type (IEnumerable<object> / IAsyncEnumerable<object>) and (b) dispatch IsGenerator / IsAsync && IsGenerator to the same state-machine emitters as class declarations, for both instance and static forms. Covers this/field access, yield*, and the async/static variants. Arrow write-capture of a generator local still fail-fasts cleanly (the #674 guard) — its function-DC wiring is tracked as a follow-up (#789).

Fixes #755 (sub-cases 1 & 2) — computed symbol-keyed method follow-ups

• Sub-case 1 — reading a symbol method as a value (obj[Symbol.iterator]) returned a raw MethodInfo, so a standalone obj[Symbol.iterator]() lost this (TargetException: Non-static method requires a target). The bracket-get now wraps it in new $TSFunction(obj, method), exactly like the string-key method path; InvokeWithThis uses the bound _target for an instance method (null for a static). $TSFunction is emitted into the output DLL, so this stays standalone-safe.
• Sub-case 2 — class expressions now wire computed symbol-keyed methods through the same synthetic-method + _classes.SymbolMethods registry + .cctor registration as class declarations (building on the Compiled: generator methods in a class EXPRESSION are unsupported ("Yield not supported in this context") #765 generator routing). for…of / spread / for await / direct access all work, including the async-generator form and this-capture.

Sub-case 3 (non-symbol string/number computed keys) needs a runtime string-keyed method registry with a fallback in the hot named-property path — a distinct architectural change tracked in #791; its test stays interpreter-only.

Tests

• StaticGeneratorMethodTests — +3 static async generator tests (bare-yield + for-await; param + real await; default-param + for-loop + await inside, the full Compiled: static generator methods (static *m()) fail with "Yield not supported in this context" #778 shape — all in both back ends).
• ClassExpressionTests — +6 (class-expression generator: basic, this/ctor-param capture, yield*, static, async, static-async).
• ComputedSymbolMethodTests — flipped DirectSymbolMethodAccess_ReturnsCallable (s1) and ClassExpression_ComputedSymbolMethod_Works (s2) to both back ends, added an async class-expression symbol-method test. NonSymbolComputedMethodKey_FoldsToNamedMethod (s3) stays interpreter-only (Compiled: non-symbol (string/number) computed class method keys are unsupported #791).

The full SharpTS.Tests suite passes (13386 passed, 0 failed).

Notes

• Branch was rebased onto current main after a concurrent fix landed; the redundant build-fix hunk it briefly carried was dropped.
• Follow-ups filed: Compiled: class-expression generator methods don't support arrow write-capture of a generator local (function-DC wiring) #789, Compiled: non-symbol (string/number) computed class method keys are unsupported #791, Type checker: a class EXPRESSION method's inferred return type doesn't reach call sites (class declarations do) #793. (Interpreter: async generator with a C-style for loop whose condition reads a parameter yields nothing #788, an interpreter async-generator for-loop bug found mid-work, was independently fixed by the async-generator rewrite already on main and is closed.)