feat(pm): H59 reports a merged PR whose closing linkage mis-states a card it names

GitHub's PR->issue closing linkage is unreliable in both directions, so a
merged PR silently mis-states the state of every issue it mentions. H59 reads
H8's existing merged window a second way and files a report-only row for each
direction:

  FALSE CLOSE  the PR mentions #N, binds no closing keyword to it, and #N
               closed with the merge. The expensive half: work disappears
               from the board while reading as done, and no other row here
               can catch it because a closed card is swept by nothing.
  FALSE OPEN   the PR binds a closing keyword to #N and #N is still open.
               The cheap half: it surfaces as queue noise.

Measured on the live board before writing the predicate: the `closed` event
carries no `commit_id` at all on this repo's landing path (six cards plus one
page of the repo-wide event stream, zero stamps), so the commit leg is kept
for the commit-message surface and the temporal leg is what carries here.
The band is measured rather than chosen - 321 keyword-bound pairs sit at
p50 1s / p95 2s / p99 4s - and the ruling's one-minute reading is narrowed to
5s because a minute admits a seat closing a card 53s after a merge. A sibling
PR that declared the closure inside the same band explains it and the row
stays quiet; without that guard two of three live candidates are wrong.

Report-only: exit codes unchanged, no label written, nothing reopened. The
remedy names the owning seat's act. Direction (b) costs no request; direction
(a) buys one bounded timeline page for the handful of cards that survive every
free narrowing, capped per sweep with the shortfall printed, and no retry on
any status.

Claude-Session: https://claude.ai/code/session_01YKEjmbYNvYWJvWGSWx26zK
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude