buzz workflows delete accepted but deleted workflows still appear in list/get (and update resurrects them)

**Describe the bug**
`buzz workflows delete` returns `accepted:true` and the relay logs `Workflow deleted via NIP-09 a-tag (UUID)`, but the workflow still appears in `buzz workflows list` and `buzz workflows get` afterwards. Worse, a subsequent `buzz workflows update` with the same workflow UUID succeeds and "resurrects" the workflow. The CLI's list/get paths query kind:30620 events, which are never tombstoned by the NIP-09 deletion.

**Steps to reproduce**
1. `buzz workflows create --channel --yaml 'name: t\ntrigger: {on: webhook}\nsteps:\n - id: s1\n action: send_message\n text: hi'` → note `workflow_id` (e.g. `e4103c08-…`)
2. `buzz workflows delete --workflow e4103c08-…` → returns `{"accepted":true,...}`
3. `buzz workflows list --channel ` → the workflow is STILL listed
4. `buzz workflows get --workflow e4103c08-…` → still returns the full definition
5. `buzz workflows update --channel --workflow e4103c08-… --yaml '...'` → succeeds, and `get` now returns the updated definition (record resurrected from the still-queryable event)

Observed on 2026-08-05 against relay build `ghcr.io/block/buzz:main` (v0.2.0, image built 2026-08-01): 50 workflows deleted in a loop, all logged "Workflow deleted via NIP-09 a-tag (UUID)" at the relay, all still returned by list/get afterwards.

**Expected behavior**
After a successful `workflows delete`, the workflow should no longer appear in `list`/`get`, and `update` should fail with not-found rather than resurrecting it.

**Root-cause pointers (from source)**
- CLI delete sends a NIP-09 event with `a` tag `30620::`: `crates/buzz-cli/src/commands/workflows.rs` (`cmd_delete_workflow`)
- Relay deletes the `workflows` DB row and invalidates the channel cache: `crates/buzz-relay/src/handlers/side_effects.rs` (`handle_a_tag_deletion`)
- CLI list/get query kind:30620 events via the event store: `crates/buzz-cli/src/commands/workflows.rs` (`cmd_list_workflows`, `cmd_get_workflow`) — the kind:30620 definition events are never tombstoned/filtered, so deleted workflows keep being returned (and any new kind:30620 with the same d-tag re-upserts the record).

**Version and platform**
- Buzz version: v0.2.0 (relay image ghcr.io/block/buzz:main, built 2026-08-01; CLI from the same tree)
- OS: macOS host running the relay in Docker (docker-compose buzz-prod)

**Logs / additional context**
Relay log after each delete: `{"level":"INFO","message":"Workflow deleted via NIP-09 a-tag (UUID)","workflow_id":"e4103c08-…","target":"buzz_relay::handlers::side_effects"}`. Deletion events do not carry an error; the silent divergence between DB state and event-query state is the issue.