Carry waits keyed by a program's own type beside the generated loop

[jasisz]

Bug

A program with the generated loop could not also key its own Wait.poll by a sum type. The loop keys its wait by Int, and every backend names the wait's boundary from one key type per program. Repro: the probe with type Watch plus a hand-written Wait.poll(idle: Map<Watch, Wait.Item>, 10) beside Run.all().

• aver compile --target rust refused it: "this program keys one wait set by 'Int' and another by 'Watch'…".
• aver run --wasm-gc failed module validation (type mismatch: expected (ref null $type), found (ref null $type)). The registry picked Watch as the one key, and the loop's wait passed Map<Int, Wait.Item>.
• The VM already ran it.

The limit lives in capability::work::wait_key_type / wait_key_conflict, read by the wasm-gc type registry (wait_set_key, the aver.wait_poll import signature, the __rt_wait_* and __rt_result_wait_keys_ok/_err factories) and by the Rust door (the Wait.poll instantiation and the key codec).

Fix

The waits are generated per key type rather than making the boundary generic. In a program that answers a capability of its own, every wait keyed by a type other than Int is rewritten to call helpers generated for that key type in the waiting module's __ namespace:

fn __waitPollByWatch(items: Map<Watch, Wait.Item>, timeoutMs: Int) -> Result<List<Watch>, String>
    keys = Map.keys(items)
    ready = Wait.poll(__waitNumberedWatch(items, keys, 0, {}), timeoutMs)?
    Result.Ok(__waitKeysAtWatch(Vector.fromList(keys), ready, []))

The keys are numbered in the order the map puts them in, the wait runs on the Int-keyed set, and the ready numbers map back to their keys in the same order. The answer is the same one the program would have got.

• Entry module: carried inside the yield lowering, after the loop is generated, from the stamped copy the lowering already has.
• Modules with no process (dependencies): carried in pipeline::front from a checked copy, the same two-phase shape the lowering uses. This runs only when the program answers a capability and the module calls Wait.poll.

ABI

There is no ABI change. Every backend sees Int keys only, so aver.wait_poll, __rt_wait_set_order, __rt_wait_set_key_at, __rt_wait_keys_cons/_nil and __rt_result_wait_keys_ok/_err keep their names and their Int instantiation. The vendored JS adapters (tools/wasm-work/host.mjs, Robin's copy) need nothing. A recording of such a wait holds the Int-keyed wait. --target wasip2, which lowers only Int-keyed waits, now runs these programs too.

A program that answers no capability keeps the old rule and its own key type: the socket-only JS test still sees Map<Watch, Wait.Item>.

Tests

The new fixture tests/fixtures/run_wait_own_key has a loop, one wait in the entry keyed by Collecting.Watch, and a job collection keyed by Collecting.Watch in a dependency.

• run_all_spec: both paths run on the VM, the helpers are generated for both modules, and a recording of the hand-written waits replays to MATCH.
• rust_work_spec: VM/Rust parity on both paths.
• wasm_work_spec: VM parity on wasm-gc and wasip2, both paths.