test: sir_social_distancing_mixnot.stmx is unsimulatable by any backend (conveyor lives in a sub-model); #924's corpus gate would read the reject as expected #941

Discovered while adding wasm-vs-VM parity tests for the conveyor belt pass (branch conveyor-engine, step 1 of #922). Blocks the acceptance criteria of #924.

Summary

The vendored fixture test/conveyors/sir_social_distancing_mixnot.stmx cannot be simulated by any backend. It fails during queue_compile::compile_sim with ErrorCode::ConveyorInSubmodelUnsupported, long before it ever reaches the wasm backend's own belt::reject_unsupported gate.

The model's top-level model (the unnamed <model> at lines 42–322) contains no stocks at all — it is pure module composition (<module name="Not Mixing">, <module name="Perfect\nMixing">, <module name="Not Mixing\nat all">) plus a handful of auxes. All three named models are sub-models, and both <conveyor> blocks (lines 335 and 585) are on the Infected stocks inside Not_Mixing and Not_Mixing_at_all. Conveyors in sub-models are unsupported (filed separately), so neither the VM nor the wasm path can run this file.

Why this is a problem right now

Nothing in the test suite runs test/conveyors/*.stmx end-to-end today — wiring that corpus up is precisely #924's job. #924's acceptance criterion is:

Every fixture under test/conveyors/ runs through both backends and the slabs agree at existing epsilons.

A fixture that no backend can simulate would sail through that gate as an "expected Unsupported" rather than being noticed as a gap. #924 already carries a note carving out covid19_severity.stmx (which fails on the VM path with conveyor_driven_flow_read); this fixture is a second, distinct instance of the same trap and has no such carve-out.

Note also that #924's acceptance says "Nothing under test/ changes." That directly collides with the obvious fix below — the two need to be reconciled.

The docs currently describe this fixture incorrectly

docs/design/conveyors.md §13 and test/conveyors/README.md both say the Not_Mixing submodel feeds the conveyor:

sir_social_distancing_mixnot.stmx — peterhovmand corpus, CC BY 4.0. The belt is transit-time-only, but its Not_Mixing submodel feeds the conveyor via an inflow marked isee:spreadflow="dist" ...

That reads as though the conveyor sits in the main model and the submodel supplies its inflow. In fact the conveyor is in the submodel. Both docs attribute the fixture's unusability solely to missing expected-output CSVs and unimplemented builtins (LOOKUPMEAN, PREVIOUS, other isee: builtins) and never mention that the conveyor's placement alone makes it uncompilable. A reader planning #924 would reasonably conclude the only blockers are an oracle CSV and a builtin.

Why it matters

• Silently unexercised fixture. It is checked in and referenced by two docs as an oracle for the isee:spreadflow="dist" distribution placement method (§8). It exercises nothing.
• §8 has thinner real-model coverage than the docs imply. If this is the only vendored model with a distribution spread inflow, then that placement method currently has no real-world fixture behind it.
• It will mask a real gap in wasm: drop the conveyor Unsupported reject and put conveyor fixtures under the parity harness #924. An Unsupported that is "expected" for the wrong reason is indistinguishable from one that is expected for the right reason.

Possible approaches

Pick one and make it explicit:

1. Restructure the fixture so a conveyor lives in the main model. Note this is not a small edit — the top-level model has no stocks, so there is nothing to hoist into; it would mean flattening Not_Mixing into the top level, which changes a vendored CC BY 4.0 model and conflicts with wasm: drop the conveyor Unsupported reject and put conveyor fixtures under the parity harness #924's "nothing under test/ changes".
2. Simulate a sub-model directly by compiling with Not_Mixing as the main model. If the engine supports selecting a non-default main model, this makes the conveyor a main-model stock with no edit to the file at all. Worth checking first — it is the cheapest option and preserves provenance.
3. Explicitly annotate/exclude it from the wasm: drop the conveyor Unsupported reject and put conveyor fixtures under the parity harness #924 corpus with a recorded reason (mirroring the covid19_severity.stmx carve-out), so "rejected" is never silently read as "expected". If excluded, say what would have to change for it to be re-included.

Whichever is chosen, correct the fixture description in docs/design/conveyors.md §13 and test/conveyors/README.md to say the conveyor is inside the submodel, and note the resulting §8 coverage gap if the fixture stays dark.

Components affected

• test/conveyors/sir_social_distancing_mixnot.stmx
• test/conveyors/README.md, docs/design/conveyors.md §13 (incorrect fixture description)
• tests/integration/simulate.rs — simulate_special_path / wasm_parity_hook, where wasm: drop the conveyor Unsupported reject and put conveyor fixtures under the parity harness #924 will add the corpus

Context

Identified during #922 step 1. Depends on the disposition of the conveyor-in-submodel limitation (filed separately). Directly gates #924; related to #884.