work-unblock: re-label reopened red-main fix issues so the issue lane starts #8881

A red-main fix issue that a recurrence reopens keeps agent-ready but never starts a lane run, so the fix waits until someone relabels it by hand.

Problem

Once #8805 lands, post-merge-demotion-alert.yml reopens a red-main fix issue on a repeat failure and keeps agent-ready without re-triage (owner decision, "go w/ recommended", relayed by Attended Build 2026-10-21). The reopen runs on that workflow's GITHUB_TOKEN. Events made with GITHUB_TOKEN start no new workflow runs, and work-resolve-issue.yml starts only on issues: labeled, so no lane picks the reopened issue up.

Proposed fix

work-unblock's hourly sweep already holds the lanes App token. Extend it to find open agent-ready issues that a recurrence reopened, identified by the recurrence comment #8805's reopen path posts, and remove and re-add agent-ready with the App token, so the labeled event starts work-resolve-issue.

• Count the matches before relabeling and log the count.
• Skip an issue that already has an open lane PR, or a run in flight for it.
• Relabel each reopen once, keyed on the recurrence comment, so the hourly sweep does not keep re-firing it.

Acceptance

• When feat(pr-pipeline): file fix issues for red-main checks and send them to intake #8805's path reopens a fix issue, work-resolve-issue starts within one sweep with no human action.
• An issue with a lane PR already open is not relabeled.
• A test covers the marker match and the skip rules.

Refs: #8805