Add operator re-queue command for stranded summary jobs

[github-actions[bot]]

Originally posted as issue #2459 by @jxt1009
#2459

Summary

When the worker or queue path is unhealthy, session summary jobs can be persisted in observation_generation_jobs but never make it back onto the summary queue after the system recovers. Today the generic retry flow is aimed at failed/cancelled jobs and treats already-queued jobs as a no-op, while startup reconciliation only republishes on startup. We need an operator command/flow to republish stranded queued session_summary jobs without requiring a restart.

Why this matters

• Temporary config changes or worker issues can leave summaries unprocessed.
• Once the worker is healthy again, those queued summaries may stay stranded.
• Operators need a safe, auditable recovery path.

Proposed direction

• Add a targeted re-queue operator flow for session_summary jobs in queued state.
• Reuse the persisted payload and deterministic BullMQ job ID.
• Keep Postgres canonical and BullMQ transport-only.
• Reuse the existing audit/logging patterns from retry/cancel.

Acceptance criteria

• Operators can republish stranded queued summary jobs without a restart.
• The first implementation supports bulk requeue for scoped queued summary jobs.
• The flow is idempotent and scoped.
• Existing retry behavior for failed/cancelled jobs remains unchanged.
• Tests cover the new behavior and operator docs explain when to use it.

Notes

• The per-ID retry path already exists for failed/cancelled jobs; the real gap is bulk queued summary republish.
• The main product choice still open is the initial operator surface: CLI, HTTP, or both.