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

[bpowers]

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.

[bpowers]

Second bad fixture, same trap as the covid19_severity.stmx note: test/conveyors/sir_social_distancing_mixnot.stmx cannot be simulated by any backend either. Its top-level model has no stocks (pure module composition) and both conveyors are Infected stocks inside the Not_Mixing / Not_Mixing_at_all sub-models, so queue_compile::compile_sim rejects it with ConveyorInSubmodelUnsupported before the wasm gate is ever reached.

Filed as #941 (fixture disposition) and #940 (the underlying conveyor-in-submodel limitation, which is undocumented). Flagging here because this fixture would otherwise pass this issue's corpus gate as an 'expected Unsupported'. Note also that #941's most obvious fix collides with this issue's "Nothing under test/ changes" acceptance criterion -- worth reconciling before starting.

Found during #922 step 1.

[bpowers]

Scope update from the conveyor wasm lowering work on branch conveyor-engine: item 3 (removing QueueOutflowKind::Coupled's explicit rejection in the queue lowering) was completed early, as part of #922 step 3 -- conveyor-to-queue coupling is now lowered on both sides (module::Passes::emit_coupled_step_body + QueuePass::emit_coupled_serve, reading the VM's own CouplingTable), and passes::reject_coupled_outflows no longer exists.

What remains here is items 1, 2, and 4: delete the up-front project_has_conveyor gate (module.rs), add test/conveyors/*.stmx to simulate_special_path, and correct the four docs.

Two constraints to carry: belt::reject_unsupported's container-access arm must stay until #923 lands, and its non-beginning spreadflow arm must stay until #946 is resolved (both are loud Unsupported rejects, not silent gaps). Also note per #944/#941: neither covid19_severity.stmx (ConveyorDrivenFlowRead) nor sir_social_distancing_mixnot.stmx (ConveyorInSubmodelUnsupported) can join the corpus yet -- both rejections are pinned on their specific ErrorCode by tests in wasmgen/belt_tests.rs.