docs(azure): make the R6 status true to what landed and what is still owed

[ruby-dlee]

Why

R6's status line still read NOT DONE and its Work list still described work that merged in #264. This document's own rule is that every state line is a claim that must be re-checkable before it is relied on, so a stale status is a defect in it.

A verification pass then found ten findings against the first version of this rewrite, three merge-blocking. This branch addresses all ten, and then removes the false claim at its source rather than only where it was quoted.

The image claim was wrong, and is refuted rather than softened

The previous text said the fm-ccm image carries no pi binary and the Azure-compartment lane needs a rebake. That is refuted:

• Config model_image_id has named gallery version 1.0.1787092687 since 2026-08-18T22:45Z. It was published 2026-08-18T22:38:08Z from managed image img-fm7c799d-ccm-1.0.1787091895.
• That managed image carries pi-tarball-sha256 a69a1859... and node-tarball-sha256 d60acfe0..., matching docs/azure-crosscheck/model-image-closure.json for pi-coding-agent 0.84.1 and Node v22.23.2. Only a build from the Pi-carrying declaration added in feat(crosscheck): carry the Pi reviewer closure in the Azure model image #246 writes those tags; the previous image img-fm7c799d-ccm-1.0.0 has neither.
• Its Image Builder run succeeded between 22:26:20Z and 22:36:46Z on 2026-08-18, after feat(crosscheck): carry the Pi reviewer closure in the Azure model image #246 landed on main at 20:51:35Z. The declaration asserts /usr/local/bin/pi --version against a tracked version twice under set -eu, before and after the credential purge, and bin/fm-crosscheck-azure-image.sh builds only from the tracked declaration at a HEAD already landed on public main, so a build that reached distribution could not have omitted pi.

The 2026-08-16 measurement was correct about the previous gallery version 1.0.1786915905. It was already stale when it was written into docs/azure-crosscheck.md in #264 on 2026-08-20. Its "ledger M29" citation is kept rather than dropped: it is not dangling, it lives in the owner's mutation ledger outside this repository, which the corrected text now says explicitly.

The operative reason the Azure compartment crosscheck lane is not running is that $FM_HOME/config/crosscheck-azure.json has "enabled": false, an operator flip on 2026-08-20. That flag, not the image, is what stands between the lane and a run.

Corrected at the source, and everywhere that depended on it

docs/azure-crosscheck.md is where the sentence originated and is corrected here, along with two neighbouring sentences that depended on it: the instrumentation follow-up described as "bound to the image rebake", and the phases paragraph attributing the lane's silence to a missing image capability.

C1 merged in #274 while this branch was open and had built five further claims on the same premise. All are corrected, and one of them was independently wrong:

• C1 stated the compartment lane is disabled "(no config/crosscheck-azure.json)". The file exists, carries enabled: false, and names a current model_image_id. It is neither absent nor waiting on an image.
• The status line and the order-of-work entry no longer say the phases wait on a rebake.
• The argument that the 75 minutes cannot have come from a compartment run on or after 2026-08-16 is withdrawn rather than restated, because its premise was the false claim.
• "unmeasurable" becomes "unmeasured", which is a reversible condition: switching the lane on and taking one compartment review would settle it.
• C1's "known contradiction" paragraph is resolved rather than left stale, since R6's status line no longer reads NOT DONE. It now carries the correction that matters to C1: GLM has never completed a review, so the pi-codex fallback is what served C1's one measured run.

The R6 status no longer overclaims

BUILT AND SERVING becomes BUILT 2026-08-20; no GLM review has ever completed, with the buried fact first: six GLM attempts on 2026-08-20 all recorded tool-failure with no citations and no execution proof, a seventh sits in the archived ledger, and the lane's only verdict came from the pi-codex fallback. The current roster state is reflected, including the restored fallback entries with config/crosscheck-same-model on as the sanctioned degraded mode.

Other corrections

• The day's token figure was one hour reported as a day. Deployment metrics give 727,136 for 2026-08-20 (515,965 + 135,911 + 75,260 across the 04:00Z, 05:00Z and 06:00Z hours); the old "about 510K" was the 04:00Z hour alone.
• The reasoning_effort probe is restated as an unretained observation; no request or response capture exists.
• The "about five tool turns" figure is removed. No GLM run record carries a turn count; the only reviewer_turn_count in the ledger is on the codex fallback run.
• Both deployment limits are stated, 25,000 tokens and 25 requests per minute, and the attribution to the token limit is labelled inference: the 429 body names neither.
• What killed each attempt is replaced with what the ledger records. Attempts 0 and 1 died on a local harness fault before reaching the provider; 2 through 4 recorded only the parser defect fix(crosscheck): follow pi auto-retry events in the reviewer stream #268 fixed, which masked the underlying error so nothing records it; only attempt 6 records a 429. Index 5 is the fallback run, not a GLM attempt.
• The zeroed GLM cost table (tests/fm-crosscheck.test.sh:1046) is recorded as a spend-visibility gap: the ledger records no per-review cost for the new primary reviewer, which is the same ledger R10's daily_budget_usd waits on.
• The Cost Management no-charge implication is dropped while keeping the fact, since C3 in this same file documents the lag.
• Three Work items that appeared in neither list are now covered: the missing status command (bin/fm-crosscheck.py exposes only run, verify, merge), the unverified reasoning_content tolerance, and review guards never re-sized for a 1M-token model.

R9 is deliberately left alone. It already says a pi review on the current model image is unproven, which stays true and is consistent with the corrected text: the binary being present and a review completing are separate claims.

Verification

Docs only, two files; no code paths touched. Rebased onto main after #274 merged. The image findings come from read-only az sig image-version show, az image list, and image-template run status against gallery fmcellgallery / definition fm-ccm; the token and error figures from read-only az monitor metrics list on aif-fm7c799d-eus01; the per-attempt outcomes from the retained crosscheck ledgers. No Azure resource was created, modified, or deleted.