t27b ledger steward: rules and job card, so spec PRs stop editing the ledger #8654

Item 1 of the efficiency plan (see #8637); the ratchet problem is described in #8321 (option 3).

Problem

Spec PRs land without a row in docs/reports/t27b_expectations.json, master's t27b-native-ratchet goes red (UNLISTED) for every PR, and parallel lanes conflict on the file. The loop fixed it by hand three times in two days: see #8289 (9 rows), #8548 (58 row changes) and #8646 (9 rows).

This issue

• specs/tri/t27b/ledger_steward.t27: which ratchet findings on a master run the steward applies by itself (UNLISTED, UNEXPECTED PASS, STALE, a cap rise covered by new rows), and which it refuses and reports (UNEXPECTED FAILURE, MOVED, BAD REASON, OVER CAP, a defect where the reference passes, a cap rise larger than the new rows, a STALE flood). The three hand batches are its test vectors.
• specs/jobs/t27b_ledger_steward.t27: the job card (CHECK, EFFECT and WAIT steps) the Queen runs on a master run.
• A note for spec authors in the t27b-loop skill.

The Queen runtime cannot run the card yet; the missing effect kinds go to a gHashTag/trios issue.

Acceptance

• t27c and t27b both pass both specs with runtime asserts; each spec has its seal and its ledger row.

User Scenarios

• Given a master run produces ratchet findings (UNLISTED, UNEXPECTED PASS, STALE, cap rise covered by new rows), When the ledger steward runs, Then it applies those findings to docs/reports/t27b_expectations.json automatically.
• Given a master run produces ratchet findings (UNEXPECTED FAILURE, MOVED, BAD REASON, OVER_CAP, reference passes, cap rise larger than new rows, STALE flood), When the ledger steward runs, Then it refuses to apply them and reports them for human review.
• Given the three historical hand-fix batches (t27b ledger: rows for 9 specs merged without one (Closes #8287) #8289, t27b ledger: master's native run at c9d36f314, row by row (Closes #8322) #8548, t27b ledger: rows for 9 more specs that landed without one (Closes #8645) #8646) as test vectors, When the steward spec is compiled and run, Then each vector is classified correctly as auto-apply or human-review.

Requirements

• FR-001: specs/tri/t27b/ledger_steward.t27 MUST define the classification rules for every ratchet finding kind listed in the issue.
• FR-002: specs/jobs/t27b_ledger_steward.t27 MUST define a job card with CHECK, EFFECT, and WAIT steps that the Queen runtime can execute on a master run.
• FR-003: Both specs MUST compile with t27c and pass t27b runtime asserts, each producing its seal and its ledger row.
• FR-004: The steward MUST read and write docs/reports/t27b_expectations.json without causing parallel-lane conflicts.

Success Criteria

• t27c specs/tri/t27b/ledger_steward.t27 compiles and t27b specs/tri/t27b/ledger_steward.t27 runs with exit 0, producing a seal and a ledger row.
• t27c specs/jobs/t27b_ledger_steward.t27 compiles and t27b specs/jobs/t27b_ledger_steward.t27 runs with exit 0, producing a seal and a ledger row.
• The three historical batches (t27b ledger: rows for 9 specs merged without one (Closes #8287) #8289 9 rows, t27b ledger: master's native run at c9d36f314, row by row (Closes #8322) #8548 58 rows, t27b ledger: rows for 9 more specs that landed without one (Closes #8645) #8646 9 rows) are encoded as test vectors in the steward spec and each vector yields the expected classification (auto-apply vs human-review).
• No UNLISTED findings remain on master after the steward job runs on a clean master run.

Boundary

• specs/tri/t27b/ledger_steward.t27
• specs/jobs/t27b_ledger_steward.t27
• docs/reports/t27b_expectations.json
• specs/trinet/ledger.t27
• specs/tri/t27b/steward.t27
• scripts/tri_loop/t27b.py
• compiler/cli/spec.t27