fix(relay): retire the kind:30620 event on workflow delete (#2879)

[bonpiedlaroute]

Fixes #2879.

Summary

buzz workflows delete removed the workflow row and invalidated the engine
cache, but left the kind:30620 definition event live. workflows list and
workflows get both read that event, so every inspection surface kept
reporting a workflow that workflows trigger rejected with
invalid: workflow not found. The only way to discover the deletion had
landed was to trigger it.

Cause

handle_a_tag_deletion's KIND_WORKFLOW_DEF arm returns after
delete_workflow_for_owner + invalidate_channel_workflows, so the generic
NIP-33 arm below it — the only caller of soft_delete_by_coordinate — is never
reached for kind:30620. Every other addressable kind, kind:30023 included, is
soft-deleted so REQs stop returning it.

Change

Extract the soft-delete block into soft_delete_addressable_coordinate and
call it from both arms. No new logic: the behaviour already existed, it was
just unreachable for kind:30620.

The comment above the generic arm stated the current behaviour was deliberate
("doesn't soft-delete the events row by design — that's a separate concern").
It is rewritten, since it would otherwise assert the opposite of what the code
does. My reading is that the concern it deferred is workflow row deletion
semantics, not the visibility of the definition event. Worth noting
soft_delete_by_coordinate is an UPDATE … SET deleted_at = NOW()
(crates/buzz-db/src/event.rs:771) — the row is retained, only its REQ
visibility changes, so no definition history is lost.

If the intent really was for the kind:30620 event to outlive the workflow, the
fix belongs in cmd_list_workflows / cmd_get_workflow instead, filtering out
definitions with no live workflow. Happy to switch to that shape.

Authorization

No new surface. Ownership of the a-tag coordinate is already enforced by
validate_standard_deletion_event
(crates/buzz-relay/src/handlers/side_effects.rs:234-253), which runs from
ingest.rs:1967 before the event is stored and before any side effect —
it requires target_pubkey == actor || is_agent_owner(...), otherwise
must be event author. The check is identical for both arms.

Testing

New e2e test test_workflow_delete_retires_definition_event, mirroring
test_long_form_a_tag_deletion which covers this path for kind:30023.

Verified it is a real regression guard:

• without the change: FAILED — workflow deletion should retire the definition event (got 1 events)
• with the change: ok

[bonpiedlaroute]

Flagging an overlap I should have caught before opening this: #2489 (open since
Jul 23, rebased today) fixes #2390, which is the same root cause reported four
days before #2879. It also adds a crates/buzz-test-client/tests/e2e_workflow_deletion.rs,
so the two branches would conflict on that path.

#2489 is the broader fix: one transaction under the kind:30620 coordinate
advisory lock, tombstoning every live definition for the coordinate rather than
the current one, and returning affected channels so query caches are
invalidated even when the workflow row was already gone.

This PR is the minimal version: reuse the existing soft_delete_by_coordinate
call from the generic NIP-33 arm by extracting it into a helper, so the
KIND_WORKFLOW_DEF arm stops short-circuiting past it. 2 files, +221/-32, no
schema or transaction changes.

Maintainers should take whichever fits the review budget — I'm happy to close
this in favour of #2489, and equally happy to keep it as the small-surface
option if #2489 needs more review time. Not looking to duplicate anyone's work.