An admin redelivers a failed webhook delivery from the terminal's Deliveries screen with `r` #8075

Intent: when a webhook endpoint was down, the owner sends the failed delivery again from where they read it failed, instead of waiting for the next event.

Done looks like:

• [ ] src/core/webhooks.ts gains redeliver(db, deliveryId, webhookId): a delivery in state failed belonging to that hook goes back to pending with its attempts reset and its claim cleared, so the existing worker (deliverDue) sends it on its next pass; a pending or ok delivery, or one of another hook, is refused and nothing changes. It reuses the row (the (webhook_id, event_id) pair is unique) — no new row and no new event.
• [ ] A sealed report's delivery stays refused, as enqueueForEvent refuses it (eventSealed).
• [ ] The terminal's Deliveries screen (deliveriesScreen in src/tui/screens/hooks.ts) offers r "redeliver" on a failed row to whoever may manage the hook (the screen's allowed() gate); after a press the row reads pending and a toast says queued again; on a row that is not failed the key is disabled.
• [ ] Tests: test/webhooks.test.ts (or a new test/webhook-redeliver.test.ts) proves failed → pending with attempts 0 and that ok/pending/other-hook ids are refused; test/tui-hooks-deliveries.test.ts drives r on a failed row. Both fail without the change.

Files: src/core/webhooks.ts, src/tui/screens/hooks.ts, test/webhook-redeliver.test.ts, test/tui-hooks-deliveries.test.ts

Risks: do not race the worker — a row a sender has claimed (within CLAIM_MS) is not reset. Leave the API, MCP and docs/MCP.md alone (hot); the web button follows in its own issue.

Brief: a builder at home in core + tui (scout or mason).