Support queued and interrupting user messages during agent execution

## Problem

When an agent is processing a request and generating a response, the user currently has to wait until the entire agent run has finished before sending another message.

For longer-running tasks, this creates friction and prevents the user from reacting to intermediate results, correcting assumptions, or preparing the next request.

## Proposed feature

Allow users to send messages while an agent run is still active, with two distinct delivery modes.

### 1. Queue message — `Enter`

Pressing `Enter` should submit a message as a queued follow-up.

The message is stored in a queue and automatically sent as the next user turn once the current agent run has completed.

This is useful when the user already knows what they want to ask next but does not want to wait for the current response to finish.

### 2. Steer message — `Shift+Enter`

Pressing `Shift+Enter` should send a steer message to the currently running agent as soon as technically possible.

A steer message should provide additional context, corrections, constraints, or changed priorities that may influence the remaining execution and the final answer.

Examples:

- “Please focus on the API integration part.”
- “Do not modify any files; only analyse the issue.”
- “Use TypeScript instead of Python.”
- “Stop investigating option A and continue with option B.”

Depending on the agent architecture, this could be implemented as a soft interruption, a context update at the next agent checkpoint, or—where necessary—an explicit cancellation and restart of the run with the new instruction.

## Expected behaviour

- `Enter` creates a queued message for the next user turn.
- `Shift+Enter` creates a steer message for the active agent run.
- The UI clearly communicates which mode was used before the message is sent.
- Queued messages preserve their order and are automatically submitted after the active run ends.
- Steer messages are passed to the running agent with minimal delay.
- The UI shows the current state of each message, for example:
- `Queued for next turn`
- `Delivered to running agent`
- `Will be applied at the next checkpoint`
- `Run restarted with steering instruction`
- The system should make clear when a steer message cannot affect an already completed tool call, model response, or execution step.

## Why this matters

This would make long-running agent interactions feel more collaborative and responsive. It is particularly valuable for research, tool calls, coding, file operations, and multi-step planning, where users often need to refine the direction before the full run has finished.

## Acceptance criteria

- [ ] Users can submit a message while an agent run is active.
- [ ] Pressing `Enter` queues the message for automatic submission after the current run completes.
- [ ] Pressing `Shift+Enter` sends a steer message to the active agent run.
- [ ] The user can clearly distinguish the two actions in the UI.
- [ ] Queued messages are processed in order.
- [ ] The UI exposes the delivery and application status of steer messages.
- [ ] The behaviour is documented when a steer message cannot be applied immediately.

No files or tests are named in the issue. Start by tracing the message submission path and active-run lifecycle, then identify the UI and agent execution boundaries; done means Enter queues ordered follow-ups, Shift+Enter steers active runs, statuses and limitations are visible, and the behavior is documented.

Written by the indexing model from the issue text.