spec(ci): suite ledger steward -- the corpus ledger bot's decision and job card #10204

Corpus ratchet (t27c suite --ratchet --corpus-only) is red for a fall as well as a rise: an UNEXPECTED PASS or a DISCARD IMPROVED on master fails the check until docs/reports/suite_expectations.json says so, and every PR inherits the red until someone writes a hand PR (#10172: 8 rows dropped, bench_proxy and prm re-pinned, cap 81 -> 73). specs/ci/derived_data.t27 says one bot re-derives lag on master; the t27b ledger has that bot (specs/tri/t27b/ledger_steward.t27), the corpus ledger does not.

Boundary

• In: specs/ci/suite_ledger_steward.t27 (the decision) and specs/jobs/suite_ledger_steward.t27 (the job card), plus the seals t27c writes for them.
• Out: wiring the job into lab.py or a workflow (foreign code behind owner-approved-foreign; a follow-up), the ledger itself, bootstrap/src/suite.rs, the cancelled master runs of Owner decision: let master runs finish, make ledger lag pending, then require the ratchets (epic #6595) #10193.

Scenarios

• A master run where specs now pass every phase: the steward drops their rows and lowers max_entries to the new count.
• A master run where a parse-no-discard total fell and no channel rose: the steward re-pins the total and the split.
• A master run with a new failure, a moved row, an expired row, a discard or channel rise, a missing reading, an unpinned row or a gate-failure rise: that row is refused and stays as master has it; the rest of the run is still applied.
• A run whose composed ledger would exceed the old cap, or that drops more than 16 rows: the whole run is refused, one issue, no PR.
• A run from a t27c older than its commit, a non-master run, or a run against a ledger master no longer has: SKIP.

Requirements

• FR-001: The spec MUST decide DROP for a ledger row whose spec fails no phase in the run, and REPIN for a parse-no-discard row whose total fell with no channel risen.
• FR-002: The spec MUST refuse a new failure, a moved or expired row, a discard or channel rise, a pinned row with no reading, an unpinned or self-inconsistent row, and a gate-failure rise or missing gate pin.
• FR-003: The spec MUST never write a cap rise: the cap it writes MUST agree with derived_data.bot_may_bless.
• FR-004: The spec MUST apply the steward's rows when other rows are refused, and MUST refuse the whole run on a cap rise or more than 16 drops.
• FR-005: The tests MUST be pinned on fix(ci): master green again -- stale corpus-ledger rows, census re-pin, t27mcp duplicate helpers (Closes #10171) #10172's numbers (8 drops; bench_proxy 738 -> 696, prm 521 -> 520; benchmark 315 -> 319 refused as a rise; cap 81 -> 73) and on Corpus ratchet red after #8209: constants.t27 discard channel moved (top-level-resync 37 -> 0) #8345, GoldenFloat course specs: phi_ratio, phi_split_optimality, radix_economy discard 331 tokens on master and assert false things #7804, Catalog Broken in gHashTag/t27: 5 malformed specs fixed in source, 24 negative fixtures, 23 stale #6437, TRI CLAW autofix: take the CI/CD routine off the user (all healing experience in, all through .t27/t27c/t27b/t27o) #9281, Port scripts/gen_w698.py (Python, 3 functions) to specs/port/scripts/gen_w698.t27 #8823 and Four advisory gates are red on master for inherited reasons, one cause per pull request #5497.
• FR-006: The job card MUST name the steps, and its compose step MUST NOT run --bless-expectations (bless drops the _why_entries_* notes).

Success Criteria

• The compiler's test report on both specs: every test passes, 0 vacuous.
• Seal verification on both specs reports MATCH.
• The PR adds only .t27 files and compiler-written seals.