[FEATURE]: Expose queued/injected delivery mode on user messages so agents may preserve in-progress multi-step plans

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Background

followup: "queue" is intentionally forced to "steer" mode (#24580), so messages the user sends while the agent is busy may be drained into the active loop's next model input. Downstream ordering issues are tracked in #28375 / #15696 (closed as intended), and UI-side queue/steering UX is requested in #24298, #38832, #37381 — but none of these address the model-facing side.

Problem

When an injected (steer) message arrives mid-task, the model receives it with no indication that it was queued while the agent was working. The message may appear indistinguishable from a fresh standalone instruction, in which case the agent could treat it as a full replacement of the current work item. Partially-executed multi-step plans may then be silently dropped, without any signal that outstanding steps remain.

Possible failure mode:

1. Agent is asked to perform a multi-step task (e.g. "push all 3 submodules to AUR, then run the sync workflow").
2. While a tool call for step 1 is running, the user sends a correction that only affects a later step ("use gh to trigger the sync") (The model was planning to locally simulate it).
3. The agent completes the running step, then consumes the injected message as the entire next instruction — potentially abandoning the remaining pushes and jumping straight to the gh command. Whether the other two got pushed may then go unnoticed until the user asks.

Existing mitigation on the agent side (and its limits)

OpenCode agents already have a persistent task-list tool (todowrite) that survives across turns and would normally surface "two pushes still pending" after an interruption. In this incident it was not used, so the outstanding steps existed only in the agent's previous reply and were lost. This suggests two compounding gaps rather than a single defect:

• An agent that fails to materialize its plan into todowrite has no way to resume after an injected message replaces its current instruction.
• Even with todowrite, the injected message carries no hint that it is a correction of an ongoing task rather than a fresh assignment, so the agent has no strong signal to consult its pending list first.

The requested metadata would make the second gap addressable; the first remains a model-behavior concern, but the metadata gives agents a stable reason to reconcile with their task list instead of assuming a full reset.

Requested enhancement

Expose the delivery mode / queue-origin of user messages to the model, so each incoming user message could be distinguished:

• delivery: "enqueue" / delivery: "immediate" (steer) — or a boolean such as queued: true — carried as message metadata (e.g. chat.message fields) so agents might detect an injected correction.

Benefits

• Agents could weigh an injected correction against an in-progress plan instead of assuming a full reset: finishing or explicitly deferring outstanding steps before applying the correction.
• More predictable course-correction ("I already queued a corrective message") without canceling the run or losing work — the exact use case in #24298.
• Could enable follow-up tooling on top (e.g. opencode-queue-style plugins) to tag queued entries, since a stable signal currently doesn't exist.
• Low blast radius: purely additive metadata; existing FIFO/steer delivery semantics should be unchanged.

Example payload change

// chat.message (user)
{
  condition: "text",
  role: "user",
  content: "...",
  // new:
  delivery: "immediate", // "enqueue" | "immediate"; absent = fresh reply
  queued: true,          // true when sent while a turn was active
}