feat(workflow): persist and resume approval gates (WF-08)

[brocoppler]

What this solves

Closes the WF-08 gap called out in VISION.md and ARCHITECTURE.md (known-gap #5): runs that hit request_approval were marked Failed with "approval gates not yet implemented". The resume half — grant/deny handlers, resume_workflow_after_approval, execute_from_step, workflow_approvals CRUD, migration, CLI, SDK — already existed but was unreachable because the suspend half never persisted anything. This PR wires that half. Design decisions are laid out in #2376 for sign-off.

How it works

• Executor (buzz-workflow): StepResult::Suspended now carries a PendingApproval (token, step id, resolved approver spec, message, timeout), captured where the resolved action is in scope. The approver spec is resolved before suspension — "any", 64-char hex, or npub1…, each with optional leading @. Unresolvable specs (display names) fail the step with an actionable error instead of minting an approval check_approver_spec could never authorize. Invalid timeout: strings now error at the step as well.
• Engine (finalize_run): the Failed stub is replaced with arm-then-announce: (1) create_approval row — raw token hashed by buzz-db; (2) run → WaitingApproval at the suspended step with the accumulated trace; (3) announce via the new ActionSink::emit_approval_requested. Ordering means a half-armed gate is never observable. Any persistence failure marks the run Failed; announce failures are logged at ERROR but don't fail the run (the gate is armed and grantable by token).
• Relay sink: emits kind:46010 signed by the relay keypair — d tag = SHA-256 token hash (the grant handlers' get_approval_by_stored_hash key, derived from the now-pub buzz_db::workflow::hash_approval_token, keeping every hash derivation on one definition), p tag = resolved approver or the workflow owner for "any" (so the request lands in query_needs_action), h tag when channel-scoped, and content JSON carrying the raw token, message, workflow/run/step ids, and expiry. Persist + fan-out mirror the send_message path (insert_event_with_thread_metadata + dispatch_persistent_event).

With the row minted and the run in WaitingApproval, the existing grant path (handle_approval_grant → spawn resume_workflow_after_approval(step_index + 1)) and deny path (→ Cancelled) operate unchanged — no relay handler changes.

Testing

• New unit tests for approver-spec resolution (any/hex/@-prefixed/npub round-trip via bech32, display-name and malformed inputs fail closed).
• cargo test -p buzz-workflow: 153 passed, 0 failed. cargo clippy --all-targets --all-features clean across buzz-workflow/buzz-relay/buzz-db; fmt clean.
• cargo test -p buzz-relay --lib: 719 passed; 1 failure in api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo which reproduces identically on clean main in my environment (passes standalone, fails under the parallel suite) — pre-existing flake, unrelated to this change; can file separately.
• Not yet covered: an end-to-end integration test (trigger → suspend → grant → resume → complete). The two #[ignore]d conformance rows (approval_token_is_community_confined, workflow_trigger_is_community_confined) are now unblocked — I'd like to rewrite them as a follow-up PR unless you want them in this one.

Follow-ups (deliberately out of scope)

• kind:46011/46012 lifecycle emission from the grant/deny handlers.
• Display-name approver resolution via the member directory (needs the same ambiguity policy as resolve_mention_pubkeys).
• Rewriting the two pending_lane conformance rows against the live gate.

🤖 Generated with Claude Code