wasmtime 36.0.12 cannot link wasi:cli/exit@0.2.12 — blocks moving the nightly pin forward

[avrabe]

Blocks bumping the nightly pin that #449 introduces. Not urgent while the pin
holds; blocking the moment anyone moves it forward.

The mismatch

nightly-2026-08-26 is the newest nightly on which the Codegen compile oracle job passes. On a current nightly (1.100.0-nightly, 2026-09-16) the
exec-oracle step fails:

Caused by:
    0: component imports instance `wasi:cli/exit@0.2.12`, but a matching
       implementation was not found in the linker
    1: instance export `exit-with-code` has the wrong type
    2: function implementation is missing

Nightly's wasm32-wasip2 std moved to emitting components that import
WASI 0.2.12. Both oracle workspaces pin wasmtime 36.0.12, whose
linker does not provide that interface shape.

codegen-exec-oracle/Cargo.lock:  wasmtime 36.0.12
codegen-kiln-oracle/Cargo.lock:  wasmtime 36.0.12

Measured, both directions

toolchain	exec-oracle
stable 1.96.1	PASS
nightly-2026-08-26 (1.100.0-nightly, 787af2b8c)	PASS
nightly 2026-09-16 (1.100.0-nightly, 495c385d0)	FAIL — wasi:cli/exit@0.2.12

So the break is between 2026-08-26 and 2026-09-16, and it is the toolchain's
wasip2 std, not the dependency graph.

Two things this is NOT

Recorded because both were proposed and both were wrong:

1. Not a stale-lockfile problem. codegen-{exec,kiln}-oracle/Cargo.lock
   pin spar-* 0.35.0 against a tree at 0.42.0, which is real drift worth
   fixing on its own — but regenerating them does not fix this. With refreshed
   locks the oracle still fails on nightly and still passes on stable. The lock
   diff is also only the eight spar-* version strings, with zero
   third-party movement, so nothing was "floating to newest".

2. Not specific to any one PR. It presents that way because the check shows
   SUCCESS on fix(verify): the runner shall not report success having executed zero commands (#403) #440/test(sysml2): grade the parser on 310 official models instead of our own fixtures #442/feat(cli): one table drives both dispatch and --help #443 — those verdicts are from 2026-08-26, four
   weeks stale. Any PR running the job today fails.

What closing this needs

• Identify the first wasmtime release whose linker provides
  wasi:cli/exit@0.2.12, and whether it is API-compatible with the oracle
  sources (codegen-exec-oracle/src, codegen-kiln-oracle/src).
• Bump both oracle workspaces, and while there, refresh the spar-* pins so
  the locks stop disagreeing with the tree by seven releases — the release bump
  runs cargo update --workspace and these are separate workspaces, so it has
  never reached them.
• Then move the nightly-YYYY-MM-DD pin in the six workflows forward and
  confirm the oracle still passes.

Related follow-up, not filed separately

Nothing prevents an unpinned dtolnay/rust-toolchain@nightly reappearing. A
guard in the shape of the existing tools/check_*.py — fail when a workflow
selects a toolchain without a date — would make that a red build rather than a
silent return to a moving gate.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BnBWxgVEUPdsBTLNKtrA6Z