t27b ledger: re-measure at master after #10445 merged with a stale ledger #10465

PR #10445 (issue #10416) squash-merged at 89254d2 with the t27b ledger that master already carried (max_not_pass 75, 177 specs unlisted): the merge happened at head fd3952d, before the ledger was re-measured at that tip. t27b-native-ratchet therefore stays red on master (UNLISTED 177) and every open pull request inherits it. The corpus ledger is fine (RATCHET CLEAN at 7552b89). This issue is the remaining t27b half.

Boundary

• docs/reports/t27b_expectations.json
• No .t27 logic, no compiler source, no workflow change, no hand-written foreign code. The ledger is written by tri t27b ratchet --bless --accept-new, from a full sweep on the Railway lab, then reviewed.

User Scenarios

• Given master after this change, when t27b-native-ratchet runs, then it reports UNLISTED 0, UNEXPECTED FAILURE 0 and exits 0.
• Given a sweep that timed out a spec only because of lab load, when the ledger is blessed, then the sweep is repeated with a longer timeout so the recorded verdict is the real one.

Requirements

• FR-001: Add every spec the reference passes that the ledger does not name, with its observed t27b verdict, measured at the current master tip.
• FR-002: max_not_pass MUST NOT be raised quietly: the PR states how many added specs are blocked and what the cap moves from and to.

Success Criteria

• "t27b native" is green on the pull request and on master after merge.
• The pull request description states the cap change.