Opt-in: queue messages sent from a T3 client ahead of agent-sent messages

[AnalogCyan]

Problem

I run an orchestrator thread that worker threads and an outside relay report to with t3_thread_send. While the orchestrator is busy, each report queues and later gets its own turn. A message I type in the web or mobile client queues behind all of them in arrival order. With a steady stream of agent reports, a short correction from me has waited more than ten minutes to reach the agent.

What exists today covers part of this:

• Send now steers into the running turn. On Claude that can cancel tool calls that are waiting to run (Agent steers on Claude threads cancel tools and look like user refusals #21895, comments on Follow-up behavior: add a "steer at next tool call" mode #15287), so it isn't a safe default for every note.
• t3_queue reorder lets the agent move my message forward without interrupting anything. But it costs the agent a tool call every turn, it depends on the agent remembering, and the list entries carry no sender, so the agent can't reliably tell which queued runs are mine (queueEntry).
• Batching (Send queued messages together: a "Steer all" action and a batched queue mode #15815) would shorten the backlog, but my message would still wait behind it.

Proposal

An opt-in server setting, off by default. When it's on, a message sent from a T3 client is placed ahead of queued agent and automation messages when it is queued:

• It goes right after the last queued client message, so my own messages stay first in, first out. If there is none, it goes before the first queued message from an agent, scheduled task or webhook.
• Automatic completion deliveries keep their current priority, and the running turn is not interrupted.
• It only sets queuePosition at enqueue. Later reorders (the t3_queue tool, the UI buttons proposed in Reorder queued messages from the thread UI #29368) still work, replay stays deterministic, and whatever t3_queue_reorder can't move a message ahead of queued automatic completion deliveries #25646 decides about completions is unaffected.

The orchestrator already has the test this needs: sentByUserFromClient is what lets a client message release a held queue today. The change would sit where queuePosition is assigned, plus the setting.

Limits

This ranks by channel, not by person. Anything that sends through a client connection counts as the user, the same as for held-queue release today. Guest messages should probably not move up.

Related: #15456 and #21240 (telling user messages apart from automation), #15815, #29368, #25646.

Would you take this direction? If so, I can open a focused PR.