pm context summary.blocked and pm list-blocked ignore dependency-blocked items (inconsistent with pm next) #578

Summary

pm next (post GH-489) correctly treats items with open blocked_by dependency edges as blocked: they are excluded from the recommendation and listed in the blocked companion with open_blocker_count/blockers. But the two other surfaces agents use to assess blockage still count only status: "blocked" items and report 0 for dependency-blocked work:

• pm context (ctx) → summary.blocked: 0 at every depth (brief through full)
• pm list-blocked → count: 0

Since ctx is advertised as "a token-efficient project context snapshot for next-work decisions", an orchestrator reading blocked: 0 will conclude everything is dispatchable, while pm next (edge-aware) disagrees. Two commands, two silent definitions of "blocked".

Repro (pm-cli 2026.7.17)

pm init --pm-path /tmp/ws/.agents/pm
pm create task "alpha" --pm-path /tmp/ws/.agents/pm            # -> pm-xxxx (blocker)
pm create bug  "beta"  --pm-path /tmp/ws/.agents/pm            # -> pm-yyyy
pm update pm-yyyy --blocked-by pm-xxxx --pm-path /tmp/ws/.agents/pm

pm next --pm-path /tmp/ws/.agents/pm
#   recommended: alpha; blocked companion: beta (open_blocker_count: 1)  ✅

pm ctx --pm-path /tmp/ws/.agents/pm | grep blocked
#   blocked: 0                                                            ❌
pm ctx --depth full --pm-path /tmp/ws/.agents/pm | grep "blocked:"
#   blocked: 0                                                            ❌
pm list-blocked --pm-path /tmp/ws/.agents/pm
#   count: 0                                                              ❌

Expected

Either (a) ctx summary and list-blocked adopt the same edge-aware semantics as pm next (count items whose open blockers > 0, regardless of status), or (b) they report both dimensions explicitly, e.g. blocked_status: 0 + blocked_by_dependencies: 1, so the number can never silently disagree with pm next.

Option (a) or (b) both fix the real problem: an agent should never have to know that "blocked" means status here and edges there.

Context

• Same bug class as [dogfood] pm next summary reports blocked: 0 while blocked items exist (blocked companion missing) #489 (fixed for pm next), now for the remaining read surfaces.
• Feature: auto-unblock items when their blocked_by dependency closes (or flag them for manual review) #267's auto-unblock makes status=blocked rarer, which makes the status-only counters read 0 almost always — i.e. the counters are effectively dead fields today.