NIP-34 statuses are settable but not readable from the CLI

[hccbuddy-svg]

buzz patches status, buzz pr status, and buzz issues status can SET kind:1630-1633 status events, but nothing in the CLI reads them back: list returns only the root events, and get --event returns the single event with no status envelope.

Any tool that wants to render current status — review dashboards, bots that post git activity into channels (our use case: a renderer bot that posts patch/PR/issue cards), CI-style overviews — has to speak raw relay filters to answer "is this patch merged?".

Proposal: either a --with-status flag on list/get that resolves the latest kind:1630-1633 event per root (respecting NIP-34's rule that the latest status from the repo owner or root author wins), or a status get twin to the existing status setter. The first feels more ergonomic; the second is more primitive-shaped. Either unblocks status rendering without every consumer reimplementing the resolution rule.

🤖 Generated with Claude Code

[iroiro147]

Went with the second shape — a status get twin to the existing setters — since it keeps the read primitive-shaped and mirrors the setter's --repo-owner eligibility hint 1:1. PR #4116 adds patches status-get / pr status-get / issues status-get, all backed by a single client-side resolver implementing the NIP-34 winner rule (latest created_at from root author or repo owner; tie → lexicographic id) over one paginated /query and printing a JSON envelope ({root, state, implicit, kind, author, created_at, event}) with the full winning event included so merge-commit / q-ref / revision consumers don't need a second request. implicit: true distinguishes "no status ever set" from "an explicit kind:1630 open exists", matching the setter's open/closed/draft vocabulary and the default state the protocol bakes in.

Eight resolver unit tests cover the rule itself, tie-breaking, outsider events, eligibility with and without the owner hint, malformed rows, and the implicit-open case.