feat(cli): add issues rm so a deleted project leaves nothing behind

[mattbalza]

Problem

repos rm (#20) withdraws a repo announcement, but orphans its issues rather than removing them. kind:1621 is immutable and not addressable, so the coordinate soft-delete that repos rm uses cannot reach it. The events stay on the relay — invisible once the project is gone, and permanent.

Change

buzz issues rm --issue <event id> deletes the issue by event id, and everything published under it first: comments (kind:1) and status events (kind:1630-1633), both anchored by e.

Two relay constraints shape the implementation, and both are pinned by tests:

1. Exactly one target per kind:5 — ingest.rs rejects any deletion whose e+a tag count is not 1 ("deletion events must reference exactly one target via e or a tag"). A batch deletion is not expressible, so this is one deletion event per target.
2. The author is enforced — validate_standard_deletion_event refuses with "must be event author". The descendant query is therefore filtered to our own pubkey; otherwise someone else's comment fails the entire purge instead of being skipped.

Children go before the parent, so a failure partway through never leaves a comment anchored to an issue that is gone. A duplicate response counts as success — that is how a partially failed purge is retried.

Deliberately not reusing repos::validate_write_response: it maps duplicate to a "repository changed concurrently, retry" conflict, which here is both wrong and alarming.

Unlike repos rm, this is not reversible — an issue cannot be re-announced under the same id. The ERP is the source of truth for the content either way.

Test plan

• cargo test -p buzz-cli --lib → 278 passed (3 new)
  • deletion carries exactly one e tag and no a tag
  • a duplicate deletion is success, not an error
  • a refusal names the event it could not delete (one purge emits many deletions)
• cargo clippy -p buzz-cli --all-targets clean