t27b ledger: counts, max_not_pass and row text as t27 rules (specs/tri/t27b/ledger_rules.t27) #9023

Part of the downtime epic (linked from it). Write it in t27 only, as pure rules with tests. DRY (AGENTS.md, see #8963): first search specs/tri/t27b/steward.t27 and specs/tri/t27b/*.t27 for an existing rule (t27c dupes --name, grep -rn) and extend it instead of copying. No hand-written code in other languages (see #8236).

Today scripts/tri_loop/t27b.py (Python, about 1864 lines) holds the ledger arithmetic: ledger_counts, the max_not_pass recount, and dump_ledger's exact row text. Parallel PRs raced this count (see #8697), and agents recomposed it by hand on every merge.

Requirements

• FR-001: specs/tri/t27b/ledger_rules.t27 defines the verdict classes: pass and pass_vacuous count as passing; every other verdict is not passing. It also defines not_pass_count, and max_not_pass as exactly the not-passing count. A cap that is not exact is a finding.
• FR-002: It defines the exact text of one ledger row, as dump_ledger writes it today: {"path": "<p>", "t27b": "pass"} for a passing row, plus blocker and reason for a non-pass row. Rows are ordered by path.
• FR-003: The tests call the functions by name, with exact expected strings and counts taken from current master rows: at least one pass row, one blocked row with a blocker and reason, and a cap recount on a 5-row example.

Success Criteria

• t27c spec-status specs/tri/t27b/ledger_rules.t27 prints IMPLEMENTED
• grep -c 'fn not_pass_count' specs/tri/t27b/ledger_rules.t27 prints 1
• grep -c 'fn row_text' specs/tri/t27b/ledger_rules.t27 prints 1

Boundary

• specs/tri/t27b/ledger_rules.t27

User Scenarios

• Given the ledger arithmetic lives only in Python today, When the spec specs/tri/t27b/ledger_rules.t27 defines not_pass_count, max_not_pass, and row_text as pure t27 rules with tests, Then t27c spec-status specs/tri/t27b/ledger_rules.t27 prints IMPLEMENTED and the spec can replace the Python implementation.
• Given a ledger with at least one passing row and one blocked row with blocker and reason, When the spec's row_text function is called for each row ordered by path, Then it returns the exact JSON text {"path": "<p>", "t27b": "pass"} for passing rows and the blocker/reason structure for non-pass rows.
• Given a 5-row ledger example from current master, When the spec's not_pass_count and max_not_pass are evaluated, Then the counts match the current master rows exactly and a cap that is not exact is reported as a finding.