[Fix] Webhook deliveries remain unfinalized after audit write failures

[roomote-roomote]

​Opened on behalf of @daniel-lxs. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

• When a duplicate GitHub-family or Linear webhook finds a durable claim with no terminal status, finalize the audit row as an explicit unknown-outcome failure without running the handler again.
• Scope recovery to the provider and delivery ID, and update only rows where both terminal timestamps are still null.
• Preserve normal duplicate suppression and the existing availability-first behavior when the initial placeholder insert itself fails.
• Add real-PostgreSQL fault injection for successful and failed handler outcomes, plus duplicate, concurrency, provider-family, and insert-failure coverage.

Why this change was made

The recorders inserted a durable placeholder before invoking the handler, but only logged a failed terminal audit update. A later provider redelivery then conflicted with the placeholder and returned, leaving the row permanently nonterminal. Replaying the handler would risk duplicating non-idempotent side effects, so recovery finalizes only the audit state.

This remains independent from #2381 and #1949: those PRs use adjacent durable webhook concepts but do not own or modify these recorder paths.

Impact

After redelivery, affected audit rows now have failed_at and a self-describing unknown-outcome error instead of remaining unclassified; handler invocation count remains one. If redelivery races a still-running original handler, the provisional unknown result is atomically replaced by that handler's eventual success or failure.

The full API suite passed 2,602 tests, focused recorder coverage passed 18 tests, and repository lint, typechecks, knip, commit hooks, and pre-push checks passed. Browser proof is not applicable because this is database transaction and deduplication behavior with no rendered surface. A row can still remain nonterminal if no provider redelivery occurs, and a repeated database failure can defer recovery to another redelivery.

[roomote-community]

No code issues found. See task

_{Reviewed 77e2be5}