wasm: drop the conveyor Unsupported reject and put conveyor fixtures under the parity harness #924

Sub-issue of #884. The last step: once the belt pass, its container access, and the runtime error channel exist, remove the reject and put the conveyor fixtures under the parity harness.

Scope

1. Delete the up-front conveyor rejection at src/wasmgen/module.rs:162, so a conveyor model routes through queue_compile::compile_sim like a queue model already does.
2. Add test/conveyors/*.stmx to the integration corpus via simulate_special_path (tests/integration/simulate.rs:1323), which builds the VM side through the unified dispatch and gates the wasm side on parity.
3. Remove QueueOutflowKind::Coupled's explicit rejection in the queue lowering, since conveyor-to-queue coupling becomes reachable on the wasm path.
4. Correct the docs that assert the limitation:
   • the rustdoc above wasm_parity_hook (tests/integration/simulate.rs), which still says conveyor fixtures have no corpus entry
   • docs/design/conveyors.md section 9.5
   • src/simlin-engine/CLAUDE.md, which says the VM is the only backend that simulates a belt
   • src/libsimlin/CLAUDE.md

Why this is filed separately

Because the trap here is subtle and has already bitten once. Adding a fixture to the corpus is not the same as running it.

When the queue pass was lowered, test/queues/minimal_queue.xmile and queue_drain.xmile turned out to be simulated by neither backend: compile_vm calls compile_project_incremental directly, whose QueueNotExpanded guard fires on a live marker, so the corpus excluded them entirely. They "passed" by never running. The same is true of test/conveyors/ today.

Separately, wasm_parity_hook panics on WasmRunOutcome::Skipped -- so Unsupported is a hard failure for models in the corpus. It is not a skip. The gap was corpus membership, not the skip/fail disposition. Do not confuse the two.

Acceptance

• Every fixture under test/conveyors/ runs through both backends and the slabs agree at existing epsilons.
• Verify by mutation, not by observing green. Re-add the conveyor rejection and confirm exactly the conveyor fixtures go red on the parity gate; then perturb the wasm belt output and confirm they go red on the slab comparison. Both must fail for the right reason. A test that cannot fail is worse than a flaky one.
• Nothing under test/ changes.
• #884 can then be closed.

Note on test/conveyors/covid19_severity.stmx

That fixture currently fails to compile even on the VM path, with conveyor_driven_flow_read: variable 'death rate' references conveyor-driven flow 'contagious_deaths'. It is not a candidate for the corpus until that is resolved, and it is not evidence of a wasm bug.