Proposal: Multi-Message FIFO Queue for Follow-ups (extends #527)

[ARCJ137442]

Proposal

Extend #527 from single-slot queueing to a true multi-message FIFO follow-up queue.

#527 solved an important problem: users can queue a follow-up without interrupting the current run. That made the workflow much smoother. This proposal keeps that same non-interruptive behavior, but removes the current single-slot limitation so queued intent is not lost.

Today, the effective behavior is:

Round R is running

queue M1 -> slot = M1
queue M2 -> slot = M2   (M1 overwritten)
queue M3 -> slot = M3   (M2 overwritten)

R finishes -> run M3 only

So even if the user thinks in 3 small steps, only the last step survives.

What I am proposing is FIFO multi-message queueing:

Round R is running

enqueue M1
enqueue M2
enqueue M3
queue = [M1, M2, M3]

R finishes -> run M1
next finish -> run M2
next finish -> run M3

This preserves user intent and allows continuous multi-round execution without forcing stop-and-wait between every turn.

The API shape can stay familiar, but semantics should become append-based rather than replace-based. In practice, posting to /api/sessions/{session_id}/queue should append a new entry, queue status should return ordered entries, and users should be able to remove one queued entry or clear all queued entries.

I think this is a direct extension of #527, not a new direction: same UX principle (do not interrupt current execution), but expanded from one queued message to N queued messages.

If this direction aligns with roadmap priorities, we can open an implementation-tracking issue with concrete backend/frontend changes and an acceptance test plan.

Concept Reference

Inspiration: Codex CLI tab shortcut flow, where users can trigger queueing via Tab while the agent is still running.