Seal refresh runner: apply derived_data.t27 V_REFRESH on the lab, so no PR inherits stale-seal red #9080

Part of epic #9025 (downtime): constraint "every open PR inherits master's red".

Problem

Three merges in one day moved generated output and left seals stale on master: #9028 (gen-rust), #9059 (issue_shape, sealed with t27c 0.5.0) and #9068 (stdmem). Each time, spec-guards and coverage went red on master and on every open PR. It took three hand PRs to clear it: #9070, #9073 and #9079.

The rule for this is already written. specs/ci/derived_data.t27 says a seal's gen hash is a derived record whose inputs include the compiler. Its verdict(KIND_SEAL_GEN_HASH, EV_MASTER, BY_BOT, ...) is V_REFRESH: on master, a bot re-saves it. bot_pr_action(...) decides what happens to that bot's PR. What is missing is the runner: nothing applies V_REFRESH to seals. brain-seal-refresh.yml covers only .trinity/experience/.

A required "re-save in the same PR" check cannot close the gap on its own. Two PRs can each be current against their own base, and the second still goes stale when the first changes the compiler. The record has to be recomputed on the new head (the carry rule of specs/queen/golden_chain.t27, REGEN).

User Scenarios

• Given a merge to master that changes t27c's output, when the t27c lab finishes its master run, then every seal whose spec hash still matches but whose gen hash does not is re-saved with that master's t27c, and a bot PR touching only .trinity/seals/ is opened.
• Given that bot PR, when bot_pr_action says it may merge (base is the tip, only derived paths), then it lands with no person in the loop, and master's spec-guards and coverage are green again.
• Given a seal whose spec hash changed, when the runner reads it, then it does not re-save it: derived_data.t27 reports that case to a person instead (V_REPORT).

Requirements

• FR-001: The runner MUST take every decision from specs/ci/derived_data.t27 (verdict, bot_may_write, bot_pr_action). It MUST NOT restate the rule in Python (only-t27, see policy: hand-written code in any language but t27 may only shrink (Closes #8227) #8236; DRY, see AGENTS.md and the t27b-loop skill: DRY -- never add a spec or function that already exists #8963).
• FR-002: It MUST run on the t27c lab's master run, which already builds t27c at every master commit. It MUST NOT add a GitHub workflow.
• FR-003: It MUST re-save only gen-drift seals (spec hash unchanged), and only with the t27c built from that same master commit.
• FR-004: The PR it opens MUST touch only .trinity/seals/ and MUST reference this issue.
• FR-005: Hand-written lines in infra/t27c-lab/lab.py MUST be net <= 0 (policy: hand-written code in any language but t27 may only shrink (Closes #8227) #8236). Move what it needs into .t27 or delete equal code.

Success Criteria

• On the next master merge that moves gen output, a bot PR re-saving the drifted seals is opened within 30 minutes of the lab run.
• With the criterion above satisfied, python3 tools/check_seal_coverage.py on master exits 0 within 60 minutes of that merge, with no hand PR.
• git diff --numstat of the runner PR shows infra/t27c-lab/lab.py with deletions >= additions.

Boundary

• infra/t27c-lab/lab.py