[Improve] Guard Discord Fast retry recovery

[roomote-community]

​Opened on behalf of @zarnivoop. Follow up by mentioning @roomote, in the web UI, or in Discord.

What changed

Added a Discord Fast-handler regression test that verifies accepted turns are durably persisted, carry their lock signal and durable admission into inference, and expose both scheduled and immediate queue wakeups for retry recovery.

Why this change was made

Fast retry recovery is implemented in the shared service, but the Discord adapter boundary did not prove that it supplies the durable state and wake callbacks that make provider retries and restart recovery work. This closes that coverage gap around the post-1.0 recovery path.

Impact

There is no production behavior change. The test prevents Discord Fast requests from silently losing durable retry and restart-recovery wiring in future refactors.

[roomote-community]

1 issue outstanding. See task

• The Discord Fast regression test does not exercise the adapter's immediate retry-resume callback (apps/api/src/handlers/discord/__tests__/fast-agent.test.ts:201).

_{Reviewed ef0c52b}

[roomote-community]

This mock only exposes and invokes requestDurableRetry; the immediate recovery callback is a separate adapter contract (requestDurableResume in fast-agent.ts). Calling turnLock.durableResume exercises shutdown recovery instead, so removing or miswiring the adapter's immediate wakeup would still pass this regression test. Add requestDurableResume to the mock adapter and assert it wakes wakeParentEventNow.