t27b ledger rows carry the reference verdict key; bless rewrites only rows whose key or verdict moved #8186

Refs #8095 (verdict reuse), #6063 (t27b). Step 3 of the t27b side, after #8176 (key) and #8184 (reused count).

Boundary

• specs/tri/t27b/steward.t27 (a bless_row rule, generated with gen-c)
• scripts/tri_loop/t27b_rules.py, scripts/tri_loop/t27b.py (bless() binding only)
• cli/t27b/src/main.rs, cli/t27b/src/blockers.rs (each JSON record carries its reference verdict key)
• contrib/railway/t27b-lab/lab.py (the lab's records carry the same key)
• docs/reports/t27b_expectations.json (rows gain "key")

User Scenarios

• Given a ledger row whose verdict key equals the run's key for that spec, When tri t27b ratchet --bless runs, Then the row is written back byte for byte.
• Given a row whose key changed, When bless runs, Then the row is rewritten from the run with the new key.
• Given a run that carries no key for a spec, When bless runs, Then that row is written as today, without a key, and is never kept on a stale key.

Requirements

• FR-001: the keep/rewrite decision is a function in steward.t27 with tests; t27b.py only applies it.
• FR-002: the key in a row is the key from specs/tri/t27b/verdict_key.t27 (t27b: key reference verdicts by the generated code, not the t27c binary #8176) under which that row's reference verdict was judged.
• FR-003: a row whose t27b verdict or blocker changed is always rewritten, whatever the key says. Otherwise a t27b fix could never be blessed, and the ratchet would report UNEXPECTED PASS forever.

Open before this is built (three problems with keying the ledger)

1. The bless source has no key. --run defaults to the lab's latest.json, and the last bless (t27b ledger: bless lab run 6b6386e15 (81 unlisted, 2 up) #8059) came from it. The lab keys its reference cache with its own Python sha256 (/srv/refcache.json), not the t27b key. The lab has to publish the t27b key per record first, or bless has to use CI's run.json.
2. The host is in the key. The lab is x86_64-linux and the CI ratchet is aarch64-linux. Rows blessed from one host carry keys the other host never produces, so blessing from the other source rewrites every row.
3. Churn. Any t27c change that moves the generated code of every spec changes every key. The next bless then rewrites about 1200 lines of a file laid out one row per line so that it does not conflict (t27b ledger: counts are derived from entries, not stored -- every spec PR conflicted on the pass line #7859).

Proposal: store the host-free part of the key in the ledger, i.e. spec closure + generated code + test runner + zig without the host. Keep the host only in the reference cache, where a host-dependent verdict (#8051) must not cross. Then bless from either source agrees. Churn after a codegen change is accepted: it is the point of the key.

Success Criteria

• t27c test-report specs/tri/t27b/steward.t27 passes with the new bless_row tests, 0 vacuous.
• Blessing twice from the same run leaves the ledger byte-identical. Blessing from a run where one spec's key moved changes exactly that row.
• Added foreign lines within the 80-line budget, counted in the PR.