t27b ledger steward: the unlisted analog_cell_ax7203 row is a tip race, not a reference disagreement #11017

The t27b ledger steward's PR for master 2520ee1 (#10752) merged with the ratchet still red, naming specs/fpga/analog_cell_ax7203.t27 UNLISTED. The suspicion was that the lab reference and the CI reference disagree on that spec (zig version, a host-only import). That is not the cause; the steward judged its commit correctly.

Cause

The spec was not in the commit the steward judged. It reached master after it.

So the lab had no finding for the spec because the spec was not in its run, and the lab's verdict (APPLY: four UNLISTED rows added, one UNEXPECTED FAILURE on specs/claw/suggest_feed.t27 refused) is exactly what that commit's run states. The derived-records job in queen-publish.yml cuts the PR branch from master's tip when it opens the PR, 25 to 40 minutes after the commit it judged, and the CI ratchet judges the PR branch. Anything that landed in between without a ledger row is UNLISTED on the PR and has no row in it: here one minute separated #10578 from the branch.

The row was added later, by #10425 (535334d). The same shape recurs: master at 5261455 (#10978) is red now on specs/claw/merge_judge.t27 for the same reason.

What this issue does, and does not

The steward's rule is right and needs no new behaviour. Skipping a run because master moved would starve it: master moves faster than a run takes. The honest fix is to state this limit where the rule lives and pin the real run as a test, so nobody searches for a reference disagreement again. The remaining fix is upstream of the steward: a spec PR must carry its ledger row, and that is a gate (owner-only workflow and gate files, not touched here). Options for the owner:

1. Make t27b-native-ratchet a required check for PRs that add a specs/**/*.t27 file, so a spec cannot land without its row.
2. Accept that the steward chases the tip: each of its PRs leaves the specs that landed during its run for the next one.

Boundary

• specs/tri/t27b/ledger_steward.t27
• .trinity/seals/t27b_T27bLedgerSteward.json

User Scenarios

• Given the lab verdict APPLY for master 2520ee1 and a spec that landed on master after that commit, when a reader asks why the ratchet on the steward's PR names that spec UNLISTED, then the header of ledger_steward.t27 answers it with the run, the two commits and the times.
• Given the real findings of run 2520ee1 (one refused timeout, four rows to add, two of them non-pass), when the steward's tally functions run over them, then they give refused 1, applied 4, new non-pass 2 and the verdict APPLY, as the lab did.

Requirements

• FR-001: specs/tri/t27b/ledger_steward.t27 MUST state that a run describes the specs of its own commit and that a spec landing after it belongs to the next run.
• FR-002: The spec MUST pin the findings of run 2520ee1 as a test block over tally_refused, tally_applied, tally_new_not_pass and run_verdict.
• FR-003: The change MUST NOT edit docs/reports/t27b_expectations.json by hand, and MUST NOT make the steward skip a run because master moved.
• FR-004: The seal of the spec MUST be refreshed by t27c, not by hand.

Success Criteria

• t27c test-report specs/tri/t27b/ledger_steward.t27 --specs-dir specs passes on the Railway lab with 0 failing tests.
• The seal check on specs/tri/t27b/ledger_steward.t27 exits 0 on the lab.
• The diff touches 2 files.