t27b: bless accounts for a cap rise, doctor stops alarming on a fail the reference shares #6237

Refs #6198, #6063.

Problem

1. tri t27b ratchet --bless refused on lab run 88862a9 (594 > cap 582). The steward did the accounting by hand (chore(t27b): re-bless the expectations ledger from lab run 88862a949 #6235): 582 - 29 now passing + 41 new not-pass specs = 594. Every master merge that adds reference-passing specs repeats this by hand, and a hand count can hide an existing entry that got worse.
2. tri t27b doctor prints LAB-ERROR "t27b_fail 1" on every run. The one fail is specs/fpga/verification/build_verify.t27, which the reference fails too (a reference-path defect, outside the denominator). An alarm that always fires is an alarm nobody reads.

Change

In specs/tri/t27b/steward.t27: cap_rise_is_new(not_pass, old_cap, new_not_pass) (the rise is covered by specs new to the ledger) and is_alarm(t27b, reference) (crash and mismatch always; fail and timeout only where the reference passes). Bless prints the accounting on refusal and, with --accept-new, raises the cap by exactly the new specs; it still refuses a remainder. Doctor's LAB-ERROR counts alarms from the per-spec results.

Acceptance

• Spec tests pass under t27c test-report (t27c lab) and t27b test --check.
• Bless on run 88862a9 over the e0f894f ledger: refuses without --accept-new, writes cap 594 with it; a fixture where an old entry got worse still refuses with --accept-new.
• Doctor on the live lab no longer prints LAB-ERROR for build_verify; a fixture with a fail where the reference passes still does (control).

Boundary

specs/tri/t27b/steward.t27, gen/c/tri/t27b/steward.c, scripts/tri_loop/t27b*.py, scripts/ci t27b tests, docs/now.