engine: dormant vector.dat 2-D VECTOR SORT ORDER p block is inconsistent + genuine-Vensim multi-dim VSO semantics unverified by any live fixture #576

Problem

The dormant test fixture test/sdeverywhere/models/vector/vector.dat contains an internally-inconsistent 2-D VECTOR SORT ORDER (VSO) result block, and -- more importantly -- genuine-Vensim multi-dimensional VSO semantics are not verified by any live fixture anywhere in the corpus.

Concrete details

• test/sdeverywhere/models/vector/vector.mdl:39 defines p[DimA,DimB] = VECTOR SORT ORDER(o[DimA,DimB], ASCENDING) -- a genuinely 2-D VSO argument (not effectively-1-D).
• In test/sdeverywhere/models/vector/vector.dat the p[...] result blocks begin at line 124 (p[A1,B1] at 124, p[A1,B2] at 127, p[A2,B1] at 130, p[A2,B2] at 133, p[A3,B1] at 136, p[A3,B2] at 139). For input o = [1,2,4,3,5,5] (row-major), the fixture encodes p = [0,1,1,0,0,1], which is a per-row / sdeverywhere-specific VSO semantic.
• The engine's flattened whole-view VSO over a 2-D input (row-major increment_indices iteration + stable sort) yields [0,1,3,2,4,5] instead. So the fixture's p block disagrees with the engine's semantic and is latent incorrect/ambiguous data.
• The 1-D l/m blocks in the same vector.dat are already genuine 0-based correct -- Phase 4 (commit a82dff2, branch clearn-hero-model, which corrected VSO to genuine-Vensim 0-based 1-D semantics) correctly did NOT need to touch this file.

Why this is NOT a regression and NOT a current blocker

This fixture is dormant -- no live test consumes it:

• vector.xmile is commented out at src/simlin-engine/tests/simulate.rs:656 (// "test/sdeverywhere/models/vector/vector.xmile",).
• There is no other Rust reference to models/vector/ (only that single commented-out line).
• Phase 4's scope deliberately covered only vector_simple.dat, which IS live via simulates_vector_simple_mdl.

The deeper open question

Genuine-Vensim multi-dimensional VSO semantics are unverified by any fixture. The authoritative real-Vensim ground truth test/test-models/tests/vector_order/output.tab (real Vensim DSS 7.3.4) exercises only effectively-1-D VSO calls (SORT ORDER, SORT ORDER2A[*,Region], SORT ORDER3[Region,product,*] are all effectively 1-D over the innermost axis) -- never a genuinely 2-D o[DimA,DimB] argument. So whether 2-D VSO sorts the flattened view or per-row is currently unverified against genuine Vensim.

Why it matters

• Correctness / latent data hazard: If models/vector/ (or any genuinely multi-dimensional VSO model) is ever re-enabled or added to the live test corpus, the dormant vector.dat p block is latent incorrect/ambiguous data that would mislead an engineer (it would look like authoritative expected output but encodes a different VSO semantic than the engine).
• No authoritative cross-check: The engine's multi-dimensional VSO behavior (flattened whole-view vs per-row) has no real-Vensim reference to validate against, so a correctness bug there could go undetected indefinitely.

Component(s) affected

• test/sdeverywhere/models/vector/vector.dat (dormant fixture, p block lines 124-141)
• test/sdeverywhere/models/vector/vector.mdl (line 39: the 2-D VSO definition)
• src/simlin-engine/tests/simulate.rs:656 (commented-out vector.xmile)
• src/simlin-engine/src/interpreter.rs / VM VSO implementation (multi-dim semantics, currently flattened whole-view)
• test/test-models/tests/vector_order/output.tab (only effectively-1-D coverage today)

Possible approaches for resolution

Before any genuinely multi-dimensional VSO model enters the live corpus:

1. Obtain a real Vensim (DSS) reference output for a genuinely 2-D VECTOR SORT ORDER(o[DimA,DimB], ...) call -- e.g. run models/vector/vector.mdl (or a minimal dedicated 2-D VSO model) in Vensim and capture authoritative output.
2. Reconcile the engine's multi-dim VSO semantics (flattened whole-view vs per-row) against that real-Vensim ground truth, fixing the engine if it diverges.
3. Fix or quarantine the dormant vector.dat p block so it matches verified genuine-Vensim semantics (or delete/clearly mark it as not authoritative until verified) so it cannot mislead a future engineer who re-enables the model.
4. Gate re-enabling models/vector/ (uncommenting simulate.rs:656) on the above being done (this is in addition to the still-open VM/cross-dimension prerequisites from the now-closed engine: vector operations and ALLOCATE AVAILABLE are interpreter-only, not in VM #355/engine: uncomment vector.xmile integration test after #355 #358).

Context

Identified during the Phase 4 code review of the element-level cycle resolution work (branch clearn-hero-model; Phase 4 commit a82dff2 corrected VECTOR SORT ORDER to genuine-Vensim 0-based 1-D semantics). The reviewer verified the file:line references and the engine-vs-fixture divergence against the code. This is a follow-up data/semantics gap that the closed issues #351 ("Verify VECTOR ELM MAP / VECTOR SORT ORDER 0-based vs 1-based indexing", scoped to 1-D vector_simple) and #358 ("uncomment vector.xmile after #355", scoped to VM/cross-dim ELM MAP) do not cover.