pm context: low_level entries lack a blocked marker/blocker IDs while summary reports a blocked count (forces an extra roundtrip) #672

Summary

pm context (the "token-efficient project context snapshot for next-work decisions") reports a summary.blocked count, but the low_level item entries carry no blocked marker and no blocker IDs. An agent reading the snapshot to pick its next task can see that N items are blocked, but not which ones — forcing a second call (pm next / pm deps <id> / pm list-blocked) to disambiguate. That extra roundtrip is exactly the token/latency cost pm context exists to avoid.

Reproduction (pm-cli 2026.7.24-3)

pm init ux --pm-path /tmp/ws/.pm
pm create Task --title "Implement auth" --pm-path /tmp/ws/.pm            # ux-bdul
pm create Task --title "Write tests"    --pm-path /tmp/ws/.pm            # ux-yecf
pm update ux-yecf --dep id=ux-bdul,kind=blocked_by --pm-path /tmp/ws/.pm
pm context --json --pm-path /tmp/ws/.pm

Output (trimmed):

{
  "summary": { "active_items": 2, "open": 2, "blocked": 1, "blocked_fallback_used": false },
  "low_level": [
    { "id": "ux-yecf", "title": "Write tests",    "status": "open", "priority": 2, "order": null, "deadline": null, "assignee": null, "tags": [], "updated_at": "...", "parent": null },
    { "id": "ux-bdul", "title": "Implement auth", "status": "open", "priority": 2, ... }
  ]
}

summary.blocked is 1, but nothing on the ux-yecf entry (the blocked one) says it is blocked, nor by what. The two entries are indistinguishable on blocked-ness.

Suggested improvement

Add a lightweight, opt-in-free blocked signal to each low_level/high_level entry so the snapshot is self-sufficient for next-work triage:

• blocked: true|false (open blocked_by with at least one unresolved blocker), and
• open_blocker_count: <n> and/or open_blocker_ids: [...] (bounded, mirroring what pm next already computes for its recommended/blockers fields).

This keeps the snapshot compact (a boolean + small int) while removing a guaranteed follow-up call whenever summary.blocked > 0. pm next already derives open_blocker_count/blockers/unblocks for a single item — reusing that projection per listed item would make pm context internally consistent with its own summary counter.

Why it matters (project management = context management)

pm context is the first call an agent makes to orient. Surfacing a blocked count without the identities is the one place the snapshot is not actionable on its own; every blocked > 0 snapshot currently implies a second query. This is a pure ergonomics/token-efficiency gap in the core CLI, not a customization issue.