Workflow deletion: non-owner delete is accepted then silently ignored, and owner delete leaves a ghost kind:30620 definition event

[redirwin]

Summary

Two related defects in the workflow (kind:30620) deletion path:

1. Non-owner delete is silently ignored but acknowledged. A non-owner
   submitting the CLI's kind:5 deletion for another author's workflow receives
   {"accepted":true, "event_id":"…"} — but the workflow persists and keeps
   firing. Cause: delete_workflow_for_owner matches rows on owner, deletes
   zero rows for a non-owner, and the NIP-09 event acceptance is reported
   regardless of effect. By contrast, non-owner workflows trigger correctly
   returns forbidden — the authorization surfaces are inconsistent, and the
   delete path converts an authorization failure into false completion
   evidence.

2. Owner delete leaves a ghost definition event. A successful owner
   deletion removes the workflows DB row (engine-side: trigger then returns
   400 workflow not found) but does NOT remove or tombstone the stored
   kind:30620 definition event. workflows list (and any client rendering
   kind:30620) keeps showing the deleted workflow indefinitely.

Why it matters

accepted:true on a write that had no effect gives clients false completion
evidence. In a multi-agent channel this caused a real coordination fault: an
agent believed a scheduled workflow was deleted and provisioned a replacement,
risking duplicate scheduled runs. The ghost event then makes listings disagree
with the engine about what exists. Accepted-but-ignored writes are the same
failure shape as the announcement-update timestamp defect (#4509).

Reproduction

1. Identity A (channel member) creates a scheduled workflow W:
   buzz workflows create --channel <uuid> --yaml <def>.
2. Identity B (same channel, not owner):
   • buzz workflows trigger --workflow W → forbidden (correct)
   • buzz workflows delete --workflow W → accepted:true; W persists and
     fires on schedule (defect 1)
3. Identity A: buzz workflows delete --workflow W → engine row deleted
   (trigger → 400 workflow not found), but the kind:30620 event still
   appears in workflows list (defect 2).

Expected

• Non-owner delete: explicit forbidden, matching trigger — never
  accepted:true for a write that will be ignored.
• Owner delete: the kind:30620 definition event is deleted or tombstoned so
  listings agree with the engine.

Environment

• Self-hosted Buzz relay (Railway), deployed commit 788b3c0
• Deletion via CLI kind:5 path
  (crates/buzz-cli/src/commands/workflows.rs::cmd_delete_workflow);
  engine-side handling in delete_workflow_for_owner

[damonrand]

Confirming both defects on 0.5.4, desktop against a self-hosted closed relay (BUZZ_REQUIRE_RELAY_MEMBERSHIP=true).

Repro that led us here: a workflow created via buzz workflows create under an ops key, then attempted deletion from the desktop Workflows panel (signed-in as the relay owner). The delete reports success, the panel keeps showing the workflow as ACTIVE, and it stays schedulable — exactly defect 1. On the desktop side the cause is visible in commands/workflows.rs delete_workflow, which builds the kind:5 with current_pubkey_hex(&state) (the signed-in identity) rather than the workflow's author, so delete_workflow_for_owner matches zero rows for any workflow the current user didn't create — and nothing surfaces to the UI. Net effect for operators: a CLI/agent-created workflow is undeletable from the desktop, with no error.

Defect 2 also reproduces: after an owner-key CLI delete (relay logs Workflow deleted via NIP-09 a-tag), buzz workflows list and get still return the kind:30620 definition, so the desktop panel renders the ghost indefinitely. #2879 tracks that half specifically.

Overlaps with the self-hosted batch in #4532.