fix(gateway): un-claim budget-overflow messages stuck in processing

getPendingMessagesByConversation() flips every fetched pending row to
'processing', then pickBatchWithinBudget() may stop early on the token
budget. The tail rows that did NOT make the batch were never un-claimed,
so they stayed 'processing' forever — the recovery worker reverted them
(120s) only for the next wave to re-claim them, an infinite loop of
stuck messages that never get analyzed (saw 22 rows, some recycled for
40+ minutes).

- add computeBudgetOverflowMessages() pure helper (batchBudget.ts)
- batchScheduler un-claims overflow rows back to 'pending' before
  dispatching the trimmed batch
- recovery-worker now reverts stuck processing unconditionally (the old
  'conversationProcessing.size > 0' guard skipped the revert when the
  in-memory lock map was empty, e.g. fresh boot — exactly when stranded
  rows from a previous process need rescuing)
- 3 regression tests for the overflow helper

services/discord-gateway/src/modules/ai-moderation/batchBudget.ts

@@ -43,3 +43,22 @@ export function pickBatchWithinBudget(
 
   return batch;
 }
+
+/**
+ * Returns the messages that were fetched/claimed but did NOT make it into the
+ * trimmed batch (i.e. the tail past the token budget).
+ *
+ * The DB claim step flips every fetched pending row to `processing`; the batch
+ * trim may then stop early on the token budget. Those tail rows would stay
+ * stuck in `processing` forever unless the caller explicitly un-claims them —
+ * this helper identifies exactly which rows that is, so the caller can write
+ * them back to `pending` for the next wave.
+ */
+export function computeBudgetOverflowMessages(
+  claimed: MessageRecord[],
+  trimmed: MessageRecord[],
+): MessageRecord[] {
+  if (trimmed.length === 0) return claimed;
+  const trimmedIds = new Set(trimmed.map((m) => m.id));
+  return claimed.filter((m) => !trimmedIds.has(m.id));
+}