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

[BradGroux]

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]

I rebased this branch onto current main and traced the orphan-repair path through the relay cache rather than assuming a successful database delete completed the job.

The core transaction remains relevant. The audit found one remaining defect: when the workflow row was already missing but live definitions still existed, the database tombstoned those definitions yet returned no row channel. The relay therefore had no cache key to invalidate, so a stale query result could survive a successful orphan cleanup.

Head ea5729ef8e8c69b01de80108c3cf4dc25c233aa8 returns the complete set of affected definition channels plus the workflow-row channel, deduplicates them, and invalidates each cache. The lifecycle regression now covers the orphan-definition-only case.

The affected package suites, strict Clippy, and Rust formatting were refreshed. The non-database tests passed. Nine unrelated relay media/admin tests could not obtain this host's local PostgreSQL pool, and a serial rerun hit the same boundary. The new ignored lifecycle regression compiled, but I am not presenting the unavailable database run as passing evidence. This remains intentionally separate from legacy alias policy, Desktop refetch behavior, and the other deletion/attribution PRs noted in the updated body.

[BradGroux]

Rebased this branch onto current block/buzz main at c55e421a0.

Head moved from 0c36797ad to 7345b8420. git range-diff shows the workflow tombstone patch is unchanged, and the branch now has a direct merge base with current main.

Verification:

• The full buzz-db suite passed: 94 tests passed; 153 Postgres-backed tests remained explicitly ignored.
• All 5 branch-specific relay side-effect tests passed.
• The workflow-deletion E2E target compiled and remained explicitly ignored because no relay service was running.
• A broad relay-library run was not fully green in this local environment: 9 Postgres-backed failures reproduced on an exact main baseline with no Postgres service available. The one additional global tracing-order failure from the first branch run passed in an isolated rerun with RUST_LOG unset.
• git diff --check, DCO trailer checks, and the direct merge-base audit passed.

GitHub checks are rerunning on the new head.

[BradGroux]

Rebased onto current block/buzz main at b1b283cd4 and rechecked the competing deletion work. #3392 explicitly identifies #2489 as the broader transaction and cache-safe fix and offers to close in its favor; #2669 addresses a separate client and owner deletion gap.

The current-main audit exposed a NIP-09 safety gap in the old branch: its workflow transaction tombstoned every live definition at the coordinate, even if the signed deletion event was older than a replacement. The refreshed transaction now applies the deletion event's created_at cutoff atomically, preserves the workflow row when a newer live definition exists, and has a regression for a tombstone timestamped between two versions.

Published head: 181d7b5f8ea6c9318ee070a1f09fcf784bef694d.

Verification passed for formatting, strict Clippy across the affected database, relay, and test-client packages, and the PostgreSQL-backed between-version tombstone regression.