NIP-34 issues: no hierarchy, dependency, or frontier query — blocks issue-backed agent work pipelines

## Summary

NIP-34 issues in Buzz can hold work items but cannot express the **relationships between them**. That gap blocks using Buzz as the issue tracker for agent work pipelines, where the structure between tickets is the substance.

Filing because #3348 (signed issue routing state) already covers one of the three gaps — this issue is to ask whether the other two are wanted, and in what shape, before anyone builds them.

## What works today

Verified against the shipped `buzz` CLI and `desktop/src/features/projects/`:

| Operation | Status |
|---|---|
| Create issue (kind:1621) | works |
| Read / list issues | works |
| Comment on issue | works (`ProjectIssuesPanel.tsx:233`) |
| Labels (`t` tags) | works |
| Status open/resolved/closed/draft (1630-1633) | works |

## The three gaps

**1. No parent/child relationship between issues.**
No way to say "this issue is a child of that one." Agent planning workflows put an index/map issue at the top with child tickets beneath it; without hierarchy that collapses to a flat list.

**2. No blocking / dependency edge.**
No way to record "issue A is blocked by issue B." This is the load-bearing one: a "frontier" query — *which tickets have all their blockers resolved and are therefore claimable* — is not expressible. GitHub models this natively via issue dependencies; GitLab via blocking links.

**3. No assignee / claim.**
Appears to be addressed by #3348. Noting it for completeness, not asking for it twice.

## Related: two intermediate board states are label-only

`desktop/src/features/projects/projectIssues.mjs` maps status:

```
1633 -> Triage protocol
1631 -> Done protocol
1632 -> Closed protocol
(default) Backlog

"In Progress" <- `t` tag in-progress/active client heuristic
"In Review" <- `t` tag in-review/review client heuristic
```

The code comments this honestly ("client-side heuristics, not protocol"). But it means those two states do not survive across clients — another NIP-34 reader places those issues in Backlog. If issue lifecycle is meant to model real work-in-progress, these may deserve protocol representation rather than tag convention.

## Questions for maintainers

1. Is issue hierarchy / dependency in scope for Buzz's NIP-34 usage, or is the position that issues stay flat and structure lives elsewhere?
2. If in scope — preference between generic `e`-tag relationship tags on kind:1621 vs. a separate relationship event kind? Happy to follow whichever direction you prefer.
3. Should "In Progress" / "In Review" get protocol status kinds, or remain deliberately client-local?

Glad to send the PR for any of this once there is a direction. Asking first specifically to avoid building the wrong shape.