fix(workflow): stop deleted workflows from returning after a stale edit

[BradGroux]

Note: This is a replacement for PR #2489, which was accidentally closed when branches were force-pushed after a commit identity rewrite. The changes are identical, rebased onto the latest main.

Fixes #2390.

What users saw

A deleted workflow could return after someone edited a stale copy. A later delete removed the workflow row again, but the replacement definition could remain queryable on the relay.

What changed

Canonical workflow deletion now uses one database transaction that:

• acquires the coordinate-scoped PostgreSQL advisory lock used by kind:30620 replacement writes;
• keeps the workflow row when a live definition is newer than the signed deletion event;
• tombstones only definition versions at or before the deletion event's created_at, as required by NIP-09;
• commits the workflow-row decision and event tombstones together;
• returns every affected definition channel so relay query caches are invalidated even when the workflow row was already gone.

The timestamp cutoff prevents a replayed tombstone from deleting a newer replacement. The complete affected-channel result also closes an orphan-repair gap where the database could tombstone a definition while leaving a stale query result cached.

Safety and scope

The existing validator still proves signer authority. The database mutation independently scopes the row and definitions by community and owner.

This PR does not add a permanent resurrection ban, sweep legacy name aliases, or change Desktop refetch behavior. It complements rather than replaces the separate work on legacy/name no-op handling and effective agent-author attribution.

Verification

• cargo fmt --all -- --check
• cargo clippy -p buzz-db -p buzz-relay -p buzz-test-client --all-targets --all-features -- -D warnings
• cargo test -p buzz-db tests::coordinate_delete_spares_head_newer_than_the_deletion -- --ignored --nocapture: passed against PostgreSQL.
• The regression creates definitions before and after the deletion timestamp, proves the older definition is retired while the newer head and workflow survive, then proves a current tombstone removes both.

[BradGroux]

This is a replacement for #2489, which was accidentally closed when branches were force-pushed after a commit identity rewrite. Prior review comments and feedback are preserved on the old PR:

#2489

[BradGroux]

Rebased onto the latest main (was 36 commits behind).

Conflict resolution: main refactored command_executor.rs to use replace_parameterized_event_in_transaction with typed preconditions, replacing the manual advisory-lock + stale-write logic that this PR's commit modified. I kept main's refactored version since it supersedes the PR's command_executor change.

The PR's lib.rs addition of event_replacement_lock_key as pub was also dropped — main already has the function as pub(crate) in the same file, and the PR's workflow.rs code uses crate::event_replacement_lock_key which works with pub(crate) visibility.

The core change — atomic workflow deletion with advisory locking, timestamp-cutoff tombstoning, and affected-channel cache invalidation in workflow.rs and side_effects.rs — applied cleanly and is still needed. main's delete_workflow_for_owner is still a simple DELETE without tombstone coordination.

CI will verify the build and test gate.