fix(channels): recover exhausted final-delivery jobs

[AsperforMias]

Closes #304.

Summary

• Mark final-delivery jobs that reach the retry limit as recoverable rather than allowing them to become terminally lost.
• Redrive those jobs from the Worker scheduled handler.
• Preserve the recovery marker when a recovery enqueue fails, and clear it only after Queue acceptance.

Why

A final-delivery job that exhausted Queue retries was ACKed and sent to DLQ with no recovery path, allowing a terminal user response to be permanently lost.

Verification

• Commands: just test-file apps/api/tests/channel-final-delivery-scheduling.test.ts (15 pass); just tc-package @mosoo/api.
• Manual steps: drove a real final-delivery job through its maximum provider failure count, injected a failed recovery enqueue followed by a successful one, then exercised the actual Worker scheduled handler and queue consumer. The job remained recoverable after the first enqueue failure and was eventually delivered and ACKed.
• Not run: just check was not run; no real Cloudflare production account or remote Queue/D1 was used.

Impact

• User/API/contract changes: None.
• Generated files / GraphQL / DB / lockfile: None.
• Env or config changes: None.
• Risk and rollback: Recovery can produce a later delivery after an ambiguous Queue response; the existing job ledger remains the idempotency boundary. Revert this PR to stop new recovery scheduling.

Review

• Closest review areas: channel final-delivery retry state machine, scheduled recovery, queue idempotency.
• Known trade-offs: This PR depends on fix(api): retain channel final-delivery jobs after ambiguous Queue sends #303's durable enqueue/outbox behavior and therefore currently includes fix(api): retain channel final-delivery jobs after ambiguous Queue sends #303's commits. It is intentionally a draft and must not merge before fix(api): retain channel final-delivery jobs after ambiguous Queue sends #303. After fix(api): retain channel final-delivery jobs after ambiguous Queue sends #303 merges, this branch should be rebased onto main, leaving only the retry-exhaustion recovery change. Per repository policy, this PR targets main rather than a feature branch.
• Cloudflare boundary: no real Cloudflare production account was used. Verification exercised the real local D1/Worker/service chain, injecting Queue behavior only at the Cloudflare binding boundary.

[Yevanchen]

Reviewed the retry-exhaustion recovery path and did not find a code-level blocker in this pass. It cannot merge while Channels remains deliberately unavailable, and it is stacked on #308.

Keep it draft; if the product surface is revived, land/review #308 first, then rebase this branch so only the exhausted-delivery recovery remains and rerun current repository plus live-boundary verification.