Estate-wide re-validation of the #199/#205 closure ABI (was static-only until #225 PR2 ran it in a real wasm engine)

[hyperpolymath]

Problem

#225 PR2 surfaced that the #199 closure ABI / #205 Thenable path had never been executed in a real WebAssembly engine anywhere in the estate. PR1's skeleton was pure pass-through (no closure dispatch); PR2's continuation is the first true end-to-end exercise, and it immediately surfaced two latent defects that static verification had never caught:

• the module never exported __indirect_function_table (host dispatch impossible);
• closure_code used LocalTee where the surrounding code assumes LocalSet, leaving a 2-value stack imbalance (invalid wasm).

Both are fixed in PR #233. But the implication is estate-wide: every downstream consumer that "dogfooded" the #199/#205 surface (e.g. standards#123 rsr-certifier extension, idaptik, boj-server bridges) was static-only — compiled, never run in a wasm host. Their runtime correctness is unverified.

Proposed work

1. A minimal tests/codegen regression that exercises the Deno source-to-source host→guest callback ABI (blocks withProgress/registerCommand/onDidSave) #199 closure dispatch independent of the async transform (a plain captured-closure call through __indirect_function_table), so the shared path is protected for all closure users.
2. An audit pass: enumerate estate consumers of the Deno source-to-source host→guest callback ABI (blocks withProgress/registerCommand/onDidSave) #199/Wasm-path thenable-resolution: guest consuming a host Thenable result (blocks #103 pilot data path) #205 surface and add a real wasm-host smoke per consumer (or document why static is acceptable there).

Surfaced by #225 PR2. Refs #225, #199, #205.

[hyperpolymath]

Deliverable (1) shipped (PR #279): tests/codegen/closure_indirect_dispatch.{affine,mjs} — the #199 [fnId@0,envPtr@4] closure ABI is now engine-validated via the exported __indirect_function_table with no async/CPS transform involved (imports only env.invokeCallback, no thenableThen). This is the negative-control the http_cps_* tests cannot isolate; it protects the shared closure path for every consumer independent of #205. Full wasm harness + dune test --force 290 green.

Deliverable (2) — estate-consumer audit:

Consumer	Uses	Runtime-smoke needed?
rsr-certifier (standards#123, satellites/rsr-certifier/extensions/vscode/src/extension.affine)	full #199 closures + #205 httpPostJson/thenableThen/thenableResultJson/jsonField; ships its own wrapHandler clone (src/affine-vscode-adapter.cjs); zero wasm tests	YES — genuinely needs one (the only materially-exposed consumer; this is exactly the static-only blind spot that hid the PR2 defects)
my-lang (vscode-extension/src/extension.affine)	#199 registerCommand closures only, no #205	No — covered upstream by (1)
idaptik / reposystem	.ts generic vscode registerCommand — not the AffineScript wasm ABI	N/A
boj-server / gitbot-fleet	no .affine consumer (boj-server is the HTTP peer of httpPostJson)	N/A

Remaining tracked item: a runtime smoke for rsr-certifier in the standards repo (cross-repo; the ABI it depends on is now upstream-guaranteed by (1), so this is hardening, not a correctness gap). Leaving #235 open for that.

[hyperpolymath]

Status refresh (2026-05-30):

The original "surfaced by #225 PR2 → static-only until real-wasm-engine validation" framing is partly resolved: fix PR #233 merged 2026-05-19 with real-wasm-engine exercise of the #199/#205 closure ABI.

Remaining work on this issue:

• Estate-wide re-validation pass (run the validation rig against every .affine fixture across the estate, not just the one in stdlib Http: typed-wasm target (convergence ABI; shared with Ephapax) #225).
• Regression test capturing the failure mode that drove feat(codegen): #225 PR2 — WasmGC CPS transform, Async base case (ADR-013) #233.

Title could be re-scoped to Estate audit + regression test for #199/#205 closure ABI (post-#233) if that's clearer.