spec(SAMPLE-REASONING): W3 runs before W2, on measured recipe demand (#605)

[localai-bot]

Amends .agents/specs/reasoning-parsers.md with an ordering amendment for #605.
Spec only — no code, no row-state change.

The argument

The spec's waves were numbered without demand data. Across the 157 official
recipes (vllm-project/recipes @ 86c7777a), --reasoning-parser is passed 76
times over 20 distinct values. We resolve 15; the other 61 abort startup.

Wave	Recipe uses covered	Notable
W3 (engine-backed adapters)	43 / 76	qwen3 18, glm45 11, gemma4 6
W2 (remaining text families)	18 / 76	kimi_k2 4, poolside_v1 4
—	0	ernie45, granite, cohere_command3/4, openai_gptoss — all in W2

qwen3 alone outweighs every W2 name combined except kimi_k2 and poolside_v1.
It is also what the published Qwen3.5/3.6 recipes pass to models we already ship
token-exact and gated — the engine serves the model and rejects its own recipe's
flag.

What changes

W3 runs before W2. Within W3 the first brick is Qwen3ParserReasoningAdapter:
vllm/reasoning/__init__.py:87 registers mimo onto the same class, so two names
land for one port; glm45/glm47 share Glm47MoeParserReasoningAdapter the same
way (:55,59).

Three names added to W3: nano_v3, plus kimi_k3 and ling3 marked post-pin —
not in the registry at 5559679, recorded so they are not rediscovered.

W2 is resequenced, not cancelled. The zero-demand names stay in scope because
upstream registers them and we mirror upstream.

Verification — one gate failed, and it is not this diff

check-pr-size: clean. Staged preflight FAILED
test_cpu_x86_llamacpp_floor::test_a_contended_leg_is_discarded_and_never_summarised
with AssertionError: 4 != 2.

That gate is load-sensitive and this box is at load average 79 from parallel
builds. Reproduced on the shared checkout at clean main with no changes at
all (NO_QUIET_WINDOW after 30s, busy=125% load=48.12). This PR is one markdown
file and cannot reach a CPU floor harness. Recorded rather than claimed green —
re-verify on a quiet box or trust CI's clean runner.

🤖 Generated with Claude Code

[localai-bot]

windows-msvc-cpu / windows-msvc-vulkan red here are pre-existing, not this diff.

Tracked by #503 and #603. Recording the attribution so a reviewer does not
re-derive it:

• The baseline cannot be subtracted the usual way. windows-msvc-* are
  skipped on push to main — verified across the last three main runs
  (31687057089, 31681004124, 31680082813: windows-msvc-cpu = skipped,
  windows-msvc-vulkan = skipped). So main never establishes green for them and
  they only ever run on a PR. That is exactly the structural trap main does not compile under MSVC, and main-baseline.py reports GREEN because windows-msvc-* are PR-only jobs it never runs #503 names:
  "main does not compile under MSVC, and main-baseline.py reports GREEN because
  windows-msvc- are PR-only jobs it never runs."*
• The control is spec(SAMPLE-REASONING): W3 runs before W2, on measured recipe demand (#605) #616, which changes exactly one markdown file
  (.agents/specs/reasoning-parsers.md) and fails the same two jobs at the same
  step, "Build and execute the native Windows CPU focused gate". A one-file
  documentation diff cannot break an MSVC C++ build, so the failure is upstream of
  every PR currently open.
• windows-msvc CI is RED on main: test_backend_cross_device.cpp uses POSIX setenv/unsetenv, which MSVC does not provide #603 names one instance of the class (POSIX setenv/unsetenv, which MSVC
  does not provide). That file has since moved, but grep -rl setenv tests/ still
  returns eight test translation units on main, so the class is not closed.

Neither this PR nor #616 touches src/, include/, tests/*.cpp, or CMake.

Not claimed as green, and not waived: the jobs are genuinely failing, the cause is
recorded elsewhere, and closing it belongs to #503/#603 rather than to a records
change.

[localai-bot]

Correction to my earlier comment: the specific cause is #584, not #503/#603.

I attributed the red Windows lanes to #503 / #603 — a compile break (POSIX
setenv, absent in MSVC). I inferred that from issue titles because the run logs
were not retrievable while the run was in progress. That inference was wrong about
the mechanism.

The observed failure is a runtime crash, not a compile error:
test_openai_api_server.exe exits -1073740791 = 0xC0000409
(STATUS_STACK_BUFFER_OVERRUN) — which is
#584, "test_openai_api_server
crashes on Windows with STATUS_STACK_BUFFER_OVERRUN (0xC0000409), unmasked by the
#512 fix". The failing CI step is "Build and execute the native Windows CPU
focused gate", which does both, so a crash at the execute half presents the same
way as a build failure from the outside.

What does not change: the failure is still not attributable to this PR.

• windows-msvc-* are skipped on push to main (verified across runs
  31687057089, 31681004124, 31680082813), so no main baseline exists to
  subtract — the structural trap main does not compile under MSVC, and main-baseline.py reports GREEN because windows-msvc-* are PR-only jobs it never runs #503 names.
• The control still holds, and is now stronger: record(MODEL-MATRIX): row the 7 recipe architectures that had none (#609, #610) #625 is records-only — it
  touches no src/, include/, or product test — and fails the same job with the
  byte-identical exit status.
• test_openai_api_server is not a consumer of anything in this PR.

Recording the correction rather than editing the original comment, so the wrong
attribution does not silently disappear from the thread. My apologies to whoever
would have chased setenv.