[FEATURE]: Web UI has no way to queue follow-up messages — steer-only since queue setting was removed

Summary

On OpenCode Web (opencode web), sending a message while the agent is busy always steers it into the active turn. There is no option to queue the message as the next normal turn after the current run finishes. The previous General → Follow-up Message Behavior (Queue/Steer) setting is gone from the web UI.

Environment

• OpenCode version: 1.18.21
• Interface: Web (opencode web)
• OS: Linux

Steps to reproduce

1. Run opencode web, open a session
2. Send a long-running prompt
3. While the agent is busy, type another message and send
4. Observe: there is no Queue/Steer choice anywhere in the composer; the message is steered into the current run immediately

Expected behavior

A way to deliver a busy-session follow-up as a queued next turn (FIFO) that runs after the current run finishes — without interrupting or redirecting the active run. This matches the semantics the V2 session runner already specifies (specs/v2/session.md): steer inputs promote at the next safe provider-turn boundary, queue inputs stay FIFO and are promoted only when the session would otherwise go idle.

Actual behavior

Steer-only. Even queue-like behavior behaves as "wait & steer" — injected at a safe boundary inside the current turn — never as an independent next turn.

Context

• The Queue/Steer setting was intentionally removed in commit ae7e2eb (Apr 2026), apparently pending a proper reimplementation
• Restore attempts were closed unmerged: #29110, #29265
• A comprehensive fix (true final-token Queue + edit/cancel + wrap/halt-steer) is pending in #33247
• The V2 backend already models both delivery modes server-side (GET /session/{id}/pending, POST /session/{id}/pending/{inputID}/queue) — the gap is purely web-composer exposure

Requested solution

Expose a Queue option in the web composer for busy sessions (per-message override plus a default in settings), backed by the existing V2 delivery: "queue" support.

Verification

☑ I have searched existing issues and believe this specific gap (no queue option at all in the current web UI) is worth tracking alongside:

#5408 #6942 #8685 #12707 #16102 #18713 #20245 #21445 #22284 #24580 #32157