Three root causes patched:
1. aiAnalyzer.ts — processBatch apiFailedMessages path:
After reverting messages to 'pending', suppress shouldScheduleNext
(was true by default) to prevent scheduleConversationAnalysis from
firing immediately and racing with the recovery worker that will pick
up those same pending messages on its next poll cycle.
Also release the conversationProcessing lock immediately after the
revert so the cooldown timer (not the full processing-timeout) gates
the next attempt.
2. messages.routes.ts — POST /messages/:id/reanalyze:
Add a per-message reanalyzeInFlight Set. Concurrent requests for
the same ID now return HTTP 409 instead of issuing duplicate UPDATEs
and triggering multiple recovery worker activations.
Also narrow the SQL predicate to 'WHERE id = AND ai_status != pending'
so a click that arrives while the recovery worker already picked the
message up is a no-op at the DB level.