Activity Monitor: blocked pill never names the blocking PR, and hive's own unblock leaves rows blocked until the next enumeration #14952

Observed 2026-10-28 13:18Z on hive's hive, Activity Monitor (GET /api/stage-tracker), reviewer "Review backlog" spin-off issues #14863 / #14867 / #14868 / #14869 / #14926.

1. The blocked pill never says what blocks it

Each of those issues carries <!-- hive:blocked-on pr=hivecommons/hive#NNNN --> and a "Blocked on PR #NNNN." line (written by the review-backlog filer), and the enumeration already files them with reason blocked on hivecommons/hive#NNNN. Yet the tracker row renders a bare grey blocked pill, "Open · blocked · since 7h", caption "No stage recorded yet", and nothing in the payload names the blocker (blocked_on is the GitHub "blocked by" dependency list from #14765 and is empty here).

Fix: parse the marker (body when at hand, else the filtered reason) server-side into blocked_on_pr: {repo, number, url, state}; state from the hive's caches only (status snapshot open PRs, ForgeState, recent-merge ring — never a fresh GitHub call). Pill reads blocked on #14862 and links to the PR; tooltip Blocked on PR hivecommons/hive#14862 (open) — lifts when it merges; re-triage if closed unmerged; caption Blocked on PR #14862 — lifts when it merges; row title / aria carry it.

2. Stale blocked after hive's own unblock

#14863 / #14867 / #14869 were blocked on PR #14862, closed (superseded) at 12:41Z. The review-backlog block sweep posted <!-- hive:unblocked --> and removed blocked within seconds, and the webhook re-read patched the governor's cached snapshot (issues 7 → 10 at 12:41Z). Forty minutes later the tracker payload still listed label blocked (updated_at 06:05Z) and the UI showed them blocked.

Root cause: a reconcile enumeration that started at 12:38Z (before the unblock) finished at ~12:42Z and was stored with lastActionable.Store(actionable), overwriting the patched snapshot with its pre-unblock copy of the issues (snapshot_age went 21m → 4m in the logs). Cached eval cycles then rebuilt status from that stale snapshot; once the dashboard's 30-minute webhook replay window expired the rows reverted to blocked until the next full enumeration (~66 min). The hive's own label removal also never asked for a targeted re-read of its own — it relied on the inbound unlabeled webhook.

Fix: (a) the governor remembers applied webhook re-reads on the snapshot and replays those newer than a reconcile pass's start onto the pass's result before publishing it (compare-and-swap, so a patch landing meanwhile is not lost); (b) a github.ItemRefreshHook fired by every hive-side blocked removal (unblockIssue, 5 sites) that invalidates the tracker cache and queues the same targeted re-read an inbound label webhook gets.

The ForgeState label cache already has write-through for the hive's own label edits (forgeWriteThrough), so no change is needed at that level.