fix(workflow): atomically delete workflow definitions

[Wirenut33]

Summary

NIP-09 deletion of a workflow removed the executable workflows row but left
the live kind-30620 definition queryable. The workflow therefore still appeared
in workflows list/get, and a retry could observe inconsistent executable and
event state.

This change:

• tombstones the kind-30620 definition and deletes the owned workflow row in one
  PostgreSQL transaction
• respects the deletion event timestamp, preserving a newer replacement when a
  stale deletion arrives
• retains the existing pre-storage authorization rule that permits the event
  author or the owning human of an agent-authored workflow
• returns the deleted workflow's optional channel so the relay can invalidate
  the correct trigger cache, including global workflows with no channel

Related issue

N/A. Searches for workflow deletion definition found no related issue or PR.

The separate send_dm implementation is deliberately excluded because it is
already proposed in #2614 and discussed in #2628.

Testing

• cargo fmt --all -- --check
• cargo clippy -p buzz-db -p buzz-relay --all-targets -- -D warnings
• cargo test -p buzz-db --lib: 94 passed, 156 ignored
• Explicit PostgreSQL regressions, all passed:
  • deletion atomically tombstones the definition and removes the workflow row
  • a stale deletion preserves both the newer definition and workflow row
  • a global workflow is deleted when its definition is already absent

Manual verification after deployment:

1. Create a workflow and confirm its kind-30620 definition is returned by
   workflows list/get.
2. Publish its authorized kind-5 a-tag deletion.
3. Confirm the executable workflow and query-visible definition are both gone.
4. Publish a deletion older than a replacement definition and confirm the newer
   definition and executable workflow remain.

The repository-wide just ci run reached mobile tests after Rust lint/unit,
desktop, Tauri, web, and mobile analyze passed. It then hit an unrelated,
reproducible failure in
mobile/test/features/channels/channel_detail_page_test.dart (keeps follow mode off while a tall newest message stays visible); this PR changes no mobile
files. The relay library suite separately passed 835 tests with 38 ignored and
hit one unrelated, reproducible mesh-demo HTTP 504 in
api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo.

No deployment or live-relay change was performed.

Originating Buzz channel: ace93da2-be69-44d7-84b6-061038ca55ee (Teal Tools Main Improvements).

[Wirenut33]

The focused deletion change is ready for maintainer review. GitHub currently
reports the CI, Docker image, and Desktop Release Candidate workflow runs
as action_required, so they need approval from a repository maintainer before
the hosted checks can execute.

Local validation for the cumulative three-file diff passed:

• cargo fmt --all -- --check
• strict Clippy for buzz-db and buzz-relay
• the three PostgreSQL workflow-deletion regressions covering atomic deletion,
  stale replacement preservation, and a global workflow whose definition is
  already absent

The overlapping send_dm work was removed from this PR and its self-wake
evidence was contributed to #2628, where the existing proposal is tracked.

Could a maintainer approve the forked workflow runs and review this focused
deletion fix?