ci: run the backlog status invariant ungated, and correct #320 to the measurement

[wshallwshall]

Two fixes from the same investigation, both correcting my own work.

1. The guard gap that red main

Two guards police docs/BACKLOG.md. The number-space gate is deliberately ungated, with a comment saying gating it "would skip it on exactly the pull requests it exists to police". The status invariant was reachable only through pytest, which is gated on code == 'true' — so on a BACKLOG-only PR, the exact shape it exists to check, it did not run at all.

On 2026-08-01 that let #117 merge with a #320 banner using an emoji the invariant rejects. Docs-only, so the leg went green in seconds without compiling the suite. main was then red for every session in the repo until another session's PR tripped over it. A 0.6s markdown parse would have caught it.

One hardened guard and one unhardened guard over the same file is worse than neither — the hardened one makes it reasonable to assume BACKLOG changes are covered.

The fix turned out to be clean. The invariant already lives in a standalone stdlib script, scripts/docs/backlog_status_check.py — only argparse/re/sys/pathlib, with its own CLI. So the neighbouring step's advertised property ("git + stdlib python (no install), costs seconds") is preserved exactly. And tests/test_backlog_status_check.py imports that same module, so there is one implementation, the unit tests keep covering its edge cases, and this only adds the always-on invocation.

2. #320's diagnosis was wrong

It claimed windows-2025 "cannot service 60/s" and is "~10x slower". A 36-run sweep across all three hosted SKUs (run 30705885914, 3 repeats per cell) refutes both.

Stranded fraction:

offered	ubuntu	windows-2022	windows-2025
60/s	0, 0, 0	0, 0, 0	0, 0, 0
150/s	0, 0, 0	0, 0, 0	0, 0, 0
300/s	0, 0, 0	0, 0, 0	0, 0, 0
600/s	0, 0, 0	4.6 / 8.9 / 19.2%	25.4 / 30.7 / 31.1%

Wall time — the cleaner signal, since all three still ingest everything up to 300/s:

offered	ubuntu	win-2022	win-2025	2025 vs ubuntu
60/s	2.8s	4.7s	4.9s	1.8x
150/s	4.3s	10.1s	11.9s	2.8x
300/s	8.4s	22.0s	29.8s	3.5x

What holds: a consistent ubuntu > win-2022 > win-2025 ordering, and ~3× more stranding than its sibling at saturation. It is genuinely the slowest leg.

What is refuted: the gap is a latency gap of 1.8×–3.5×, not a capacity cliff. windows-2025 ingests everything up to 300/s — five times the rate the failing test offers — and strands 0% at 60/s in three of three runs.

So the 60/s failures remain unexplained. Real (byte-identical twice) but not a property of the SKU at that rate, or the sweep would show them. The untested variable is contention: the probe runs the engine alone on an idle runner, while the CI failure happens with the full suite alongside it in a ~20-minute job. That also matches the developer-box outlier already retracted in this item.

Consequence. This is a tolerance problem, not a throughput one — exactly what #115's widened stranding budget absorbs, so that fix is better supported now than when it was made. And the product concern this item originally raised is not supported: a 1.8×–3.5× gap on a hosted VM image says nothing about Windows Server 2025 as a deployment target.

Verification

• scripts/docs/backlog_status_check.py exits 0 — 244 items, each declaring exactly one status.
• New step asserted present, ungated (runner.os == 'Linux' only, no code condition).
• 122 backlog / required-context / workflow guard tests pass.
• Cherry-picked onto current main (2a6649fb) rather than committed against a stale base — another session had edited ci.yml meanwhile; auto-merged cleanly and re-verified after.