fix(relay): execute a-tag workflow deletions against the a-tag owner, delete all name matches, surface no-op deletions

[Orland00]

Partially addresses #1593 (the going-forward half; existing-orphan reconciliation is a separate discussion — see my comment on the issue).

Problem

Workflows whose owner can no longer delete them keep executing on their cron schedules indefinitely — recurring compute and API spend with no accountable owner and no off switch. Three execution bugs make that possible:

1. Validation/execution owner mismatch. validate_standard_deletion_event authorizes an a-tag deletion against the a-tag's pubkey (including the is_agent_owner allowance that lets a human owner delete their agent's content), but handle_a_tag_deletion parses that pubkey and never uses it — both the UUID delete and the name fallback are scoped by the deletion signer. A human owner deleting an agent-owned workflow passes validation, then silently deletes nothing.
2. Name-based deletion removes at most one of N. The name fallback used find_by_owner_and_name (LIMIT 1, no ORDER BY) + a single-row delete; with several same-named rows (there's no unique constraint on owner+name) an arbitrary one is removed and the rest keep firing.
3. No-op deletions look successful. All miss paths only tracing::warn! server-side; the client sees accepted: true with an empty message — which misled the issue reporter into declaring victory twice.

Implementation

• handle_a_tag_deletion (KIND_WORKFLOW_DEF): hex-decode the a-tag pubkey and scope both the UUID delete and the name-based delete by it. Authorization is unchanged — it already ran in validate_standard_deletion_event; this aligns execution with validation.
• New delete_workflows_for_owner_by_name in buzz-db: single DELETE … RETURNING id, channel_id removing every match; each affected channel's workflows are invalidated (deduped). find_by_owner_and_name is untouched (its only caller was this handler).
• No-op surfacing follows the existing "duplicate:" / "info:" OK-message convention in ingest.rs: the kind:5 event is stored/accepted as before, but the OK message now carries info: no matching workflow found for deletion. Plumbing: handle_side_effects returns anyhow::Result<Option<String>>; kind:5 routes separately and every other kind keeps its exact previous behavior (Ok(None)).

Behavioral note for reviewers: cross-owner deletions that previously passed validation and then silently no-op'd now actually execute — that is the intended fix, but worth a conscious look at the authz implications (validation already gated these on is_agent_owner).

Testing

Regression tests (Postgres-gated, #[ignore = "requires Postgres"], following the existing setup_pool / workflow_sink::integration_tests patterns):

• delete_workflows_for_owner_by_name_removes_all_same_named_rows (3 same-named rows → all deleted)
• delete_workflows_for_owner_by_name_leaves_other_owners_untouched
• a_tag_deletion_by_human_owner_deletes_agent_owned_workflow — the exact reported bug: agent-owned workflow, deletion signed by the human owner, a-tag naming the agent → row actually deleted. Red/green verified (temporarily reintroducing the old actor scoping makes it fail).

Ran locally: cargo fmt --all -- --check · cargo clippy -p buzz-db -p buzz-relay --all-targets -- -D warnings · cargo test -p buzz-db -p buzz-relay (82 + 715 passed; PG-gated tests run against a real Postgres 17) · cargo check --workspace. Relying on upstream CI for the full matrix (desktop/web/mobile untouched).

Deferred

• Reconciliation for already-orphaned rows (pre-Harden relay attack surfaces #1369 rows are unreachable by any client-signable event, per the issue's 2026-07-09 update) — awaiting maintainer preference on shape (migration vs startup sweep vs scripts/maintenance/), see the issue thread.

• CLI buzz workflows delete --name follow-up (the relay path now supports it correctly).

• No-op surfacing is deliberately scoped to the workflow branch; the generic NIP-33 soft-delete no-match case still no-ops silently — happy to extend the same message there if you want the consistency.

[Orland00]

Rebased onto main at b6af13b1 — the branch had gone conflicting. The only conflict was additive in crates/buzz-db/src/workflow.rs: main's new SEC-006 test (disable_for_owner_scopes_to_owner_and_channel) landed adjacent to this PR's delete_workflows_for_owner_by_name tests. Both kept, no logic touched, the diff is unchanged at 4 files / +386 / -39.

Verified locally after the rebase: cargo fmt --check clean, cargo clippy -p buzz-db -p buzz-relay --all-targets -- -D warnings clean, cargo test -p buzz-db 85/0, and the relay tests over this PR's paths green (side_effects 5/0, handlers::ingest 105/0). The Postgres-backed cases stay #[ignore]d as before.

This has been open since the 21st without a reviewer assigned — could someone who knows the relay's NIP-09 deletion path take a look? Happy to split it if the three fixes (owner-scoped execution, deleting all name matches, surfacing no-op deletions) would be easier to review separately.