#3079: Auto-compression queuing is undiscoverable (misleading tooltip, no queue cue, no placeholder hint)

Problem

When automatic context compression is triggered mid-session, the WebUI disables the composer until compression finishes. The send button greys out with tooltip "Waiting for compression to finish" (composer_disabled_compression in static/i18n.js, enforced via isCompressionUiRunning() in static/ui.js:3602–3604 and static/messages.js:300).

In practice this interrupts work: I cannot queue the next message, dictate the next instruction, or even type ahead while the compression pass runs. Compression can take a long time, especially in combination with the symptom described in #2973 (running state lingering until session end) and #2761 (assistant response vanishing into an "Auto-compressing…" card).

What I want

Either:

1. Don't block the composer during auto-compression. Let me type and submit the next turn; queue it to run as soon as compression resolves. Manual /compress could keep the current behavior since it's user-initiated.
2. Or, expose an opt-out setting — e.g. webui.compression.block_composer: false, or a per-session toggle in Settings — so users who don't want auto-compression to gate their input can turn the block off.

A "queue next message" affordance would be the friendliest of the two: input always available, with a small "will send after compression" hint.

Why this matters

• Auto-compression is involuntary from the user's perspective — it's a background housekeeping task, not something I asked for. Having it stop me from composing my next thought feels like the tool fighting me.
• Combined with the known issues where the running state can hang (#2973, #2477), the composer block can effectively brick the session for minutes at a time.
• Manual /compress is opt-in and the block makes sense there. Auto-compression should be more permissive.

Repro

1. Start a long WebUI session and run until auto-compression triggers.
2. Try to type / send a new message while the running auto-compression card is visible.
3. Send button is disabled; tooltip shows "Waiting for compression to finish".

Suggested implementation sketch

• Gate the disabled state on a new condition like isCompressionUiRunning() && (compressionKind === 'manual' || settings.blockComposerOnAutoCompress).
• Or, keep composer enabled and have the send handler enqueue the message into a small pending-queue that flushes when the compression UI clears.

Happy to scope this further or split into the toggle-only path if a queueing implementation is too involved for a single PR.

Related

• #2973 — auto-compression running state lingers until session end
• #2761 — assistant response vanishing into "Auto-compressing…" card
• #2477 — auto-compression appearing stuck during long runs
• #1834 — auto-compression toast UX