fix(concurrency): eliminate all identified double-queue and race conditions

Implements full audit from double_queue_audit.md.

## Critical

fix(backend): reanalyze-batch — per-scope in-flight guard (messages.routes.ts)
  Two concurrent admin sessions clicking 'Retry All Errors' simultaneously now
  get a 409 REANALYZE_BATCH_IN_PROGRESS for the same guildId:channelId scope.
  Prevents the recovery worker from being triggered twice for the same set of
  error messages.

fix(discord-gateway): messageUpdate embed resolution skip (messageCapture.ts)
  Discord fires messageUpdate when link previews resolve 1-2s after send
  even though the message body is unchanged. Compare newContent vs
  existingContent before resetting ai_status to pending and re-queueing LLM.
  Eliminates a spurious duplicate analysis that could overwrite a valid result.

## High

fix(discord-gateway): scheduleAutoDelete idempotency (aiAnalyzer.ts)
  Add autoDeleteInFlight Set. Both processBatch and processIndividualFallback
  call scheduleAutoDelete; without the guard, a message that races through
  both paths launches two concurrent attemptAutoDeleteFlaggedMessage calls,
  producing a duplicate moderation-action log entry and a Discord 10008 error.
  The Set is cleaned up in a .finally() block after each attempt completes.

## Medium

fix(frontend): revert optimistic pending state on HTTP failure (useMessages.ts)
  Capture the prior MessageRecord inside the setMessages functional updater
  (no extra useCallback deps needed). If reanalyzeMessage() throws, restore
  the snapshot so the UI reflects the real DB state instead of lying.

fix(discord-gateway): exclude individual_analysis_exhausted from recovery queries
  Both getConversationKeysWithIncompleteAnalysis and
  getIncompleteMessagesByConversation now add a NOT LIKE guard for
  individual_analysis_exhausted. Prevents an infinite recovery loop if a bug
  ever writes both flags to the same row.

## Low

fix(discord-gateway): unified timer path in scheduleConversationAnalysis
  Remove the separate cooldown-path that created a secondary timer calling
  scheduleConversationAnalysis recursively. Replace with a single
  clear-and-reset pattern where delayMs = max(cooldownRemainder+500, debounce).
  Eliminates the edge case where both timers were live simultaneously.

## Misc

fix(backend): cast req.params.id to String() to satisfy Express typings
  Pre-existing tsc error (string | string[]) exposed by our edit.
  String() is correct; route params are always scalar strings at runtime.

services/backend/src/modules/messages/messages.routes.ts

@@ -14,14 +14,21 @@ import { messagesService } from "./messages.service.js";
 const logger = createChildLogger("messages.routes");
 
 /**
- * Per-message in-flight guard for the reanalyze endpoint.
+ * Per-message in-flight guard for the single reanalyze endpoint.
  * Prevents concurrent spam-clicks from issuing duplicate UPDATE + recovery
- * worker triggers for the same message. Released as soon as the DB write
- * completes (or fails), which is fast enough that false-positive blocking
- * is not a practical concern.
+ * worker triggers for the same message.
  */
 const reanalyzeInFlight = new Set<string>();
 
+/**
+ * Per-scope in-flight guard for the batch reanalyze endpoint.
+ * Scope key = "guildId:channelId" (empty string used for undefined parts).
+ * Two concurrent batch-reanalyze requests for the same scope are rejected
+ * with 409 so the recovery worker is not triggered multiple times for the
+ * same set of error messages.
+ */
+const reanalyzeBatchInFlight = new Set<string>();
+
 export function createMessagesRouter(): Router {
   const router = express.Router();
 
@@ -50,22 +57,40 @@ export function createMessagesRouter(): Router {
         messageIds?: string[];
       };
 
-      const count = await messagesService.reanalyzeErrorBatch({
-        guildId,
-        channelId,
-        messageIds,
-      });
+      // Idempotency guard: one concurrent batch-reanalyze per scope.
+      // Prevents two admin sessions clicking simultaneously from each
+      // triggering the recovery worker for the same set of messages.
+      const scopeKey = `${guildId ?? ""}:${channelId ?? ""}`;
+      if (reanalyzeBatchInFlight.has(scopeKey)) {
+        res
+          .status(409)
+          .json({ error: "REANALYZE_BATCH_IN_PROGRESS", scope: scopeKey });
+        return;
+      }
+
+      reanalyzeBatchInFlight.add(scopeKey);
+      let count = 0;
+      try {
+        count = await messagesService.reanalyzeErrorBatch({
+          guildId,
+          channelId,
+          messageIds,
+        });
+      } finally {
+        reanalyzeBatchInFlight.delete(scopeKey);
+      }
 
       logger.info({ count, guildId, channelId }, "Batch reanalyze completed");
       res.status(200).json({ ok: true, count });
     }),
   );
 
+
   // POST /api/messages/:id/reanalyze - Mark single message for re-analysis
   router.post(
     "/messages/:id/reanalyze",
     asyncHandler(async (req: Request, res: Response) => {
-      const id = req.params.id;
+      const id = String(req.params.id ?? "");
       if (!id) {
         res.status(400).json({ error: "MISSING_ID" });
         return;