threadwatch: fire-once merge alert for pinned PRs (PR-merge transition detection)

[MoltyCel]

Problem. ThreadWatch pins PRs (e.g. w3c-cg/ai-agent-protocol#40 in #234), but the trigger that matters for a pinned PR is the MERGE event — that is when a deferred own-task (publish the VC-serialization annex) becomes live. Merge state was already detected (a merged pinned PR renders a persistent 🟣 MERGED roster label via analyze_pinned), but there was no distinct, fire-once transition alert — a merge just silently changed a label that is easy to miss and never says "the deferred task is now unblocked".

Change (additive, no bucket/classify logic touched).

• build_roster_entry: for a closed pinned PR, confirm merge via the canonical pulls API (GET /repos/{repo}/pulls/{n} → merged/merged_at). Only closed PRs incur the extra call; open PRs cannot be merged. This distinguishes MERGED from closed-unmerged authoritatively.
• analyze_pinned: roster entry now carries is_pr / merged / merged_at.
• main: after building the roster, compute fire-once merge alerts using a new merged_announced state map in state/threadwatch.json; the guard is persisted immediately so it fires exactly once per pinned PR.
• fmt_report: renders a distinct block at the very top: 🔀 <key> MERGED — <note>.

Verification (no network). Unit-exercised analyze_pinned/fmt_report + the fire-once loop:

• merged PR → merged=True, 🟣 MERGED, alert fires run 1 and is silent run 2 (idempotent);
• closed-unmerged → merged=False, ⬛ CLOSED (no alert);
• open PR → merged=False;
• report shows 🔀 PINNED PR MERGED at top with the pin note; absent when no merges.
  py_compile clean.

Once this + #234 are live, #40 merging by a maintainer will surface a one-time 🔀 w3c-cg/ai-agent-protocol#40 MERGED alert = the go-signal for the VC-serialization annex.