feat(pm): H4/H14/blocking-index read comment-level Blocked-by lines (#10061) (#10075)

The unlock scan and this patrol read issue BODIES only, while seats
deliberately park the `Blocked-by:` line in a COMMENT — a body rewrite
goes through the MCP escaping hazard (#8813) and is the riskier write.
26 of 40 blocked cards were body-clean at the 2026-08-19 census, so the
body-only read reported a duty as unmet that had in fact been met in the
other channel, and H14 reported #9465 and #9968 as stale caches while
their dependents (#9709/#9828, #9969/#9652) stated the wait in comments.

- H4 judges BOTH channels; either discharges the duty, and the finding
  names both so a reader knows which one to fix.
- `buildBlockingIndex` takes `options.comments` and UNIONs comment-borne
  refs with body ones — both are real edges, so neither wins.
- H14's two directions treat an incomplete index asymmetrically: stale
  (a claim about absent evidence) is suspended when any gated fetch
  failed; missing (a claim about evidence in hand) survives.
- Fetches are gated to body-clean `pm:blocked` / `pm:blocking` cards and
  share the existing `commentCache`, so a card costs one request across
  H2, H17 and this. Total failure rethrows as transport (#4690); a
  partial shortfall is stated by the summary line's third `read X of Y`.

Stated boundary: the seat protocol's read-closure cut-off (comments newer
than the body's last edit) is NOT implemented — REST carries no body-edit
timestamp and this file is REST-only; the one proxy in reach makes the
check unfalsifiable. Rationale and direction analysis at the predicates.

Self-test 414 -> 469.

Fixes #10061


Claude-Session: https://claude.ai/code/session_01AeA3nU1B5Q2pgxqxgUrexd

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-warren