Queued user messages + system_notifications delivered out of send order

## Summary

When the assistant is mid-tool-call and the user sends multiple messages and/or `system_notification`s arrive in that window, the queued items are delivered to the assistant in a non-deterministic / out-of-send-order sequence.

## Observed behaviour

In a long session that drives many background agents and async shells (typical of orchestration/supervisor workflows), the user types several short messages while a tool call is in flight (e.g. "and?", "bump", "why why why", "check again"). When the tool call returns and the assistant's next turn begins, the messages are NOT presented in the order they were sent.

Symptom from inside the loop: an older message can appear after a newer one, system_notifications interleave seemingly arbitrarily with user messages, and the assistant cannot reliably tell which user prompt is the "latest" intent.

## Expected behaviour

Queued user messages and system notifications should be delivered to the assistant in strict send-time order (FIFO per channel, or globally ordered by enqueue timestamp). At minimum, the assistant should be able to read a monotonic timestamp on each so it can re-sort.

## Impact

- The assistant answers a stale message as if it were the latest, ignoring follow-ups.
- In an operator-driven loop (supervised PR dispatch, multi-agent orchestration) the user can't trust the assistant heard the most recent instruction.
- Causes the user to repeat themselves and escalates frustration.

## Two related observations (may be the same root cause or separate)

1. **Two queues, not one.** There appear to be two delivery channels (user messages and `system_notification`s) and they are interleaved with no obvious total order. A single ordered queue would be simpler to reason about.
2. **No visible enqueue timestamp.** Each `` includes a `` that looks like the *delivery* time, not the *send* time. So even if the assistant wanted to re-sort, it lacks the data.

## Repro

1. Start a session that dispatches a 2–5 minute background tool call.
2. While it's running, send 3–5 short user messages, each ~10 s apart.
3. When the tool completes, observe the next assistant turn — the messages are not always processed in send order.

## Suggested fix

- Single FIFO queue across user messages + system_notifications, OR
- Tag each delivered item with a monotonic `enqueuedAt` so the assistant can sort, AND
- Document the ordering guarantee in the agent docs.

## Environment

- GitHub Copilot CLI v1.0.54
- Windows
- Long-running multi-agent session

## Refs

Filed at operator's explicit request after the issue reproduced multiple times in a single session.

The issue names no source files, tests, or entry points. Start by reproducing the ordering failure during a long-running tool call with queued user messages and system_notifications; done means the delivery order is deterministic or each item exposes enough enqueue-time data to establish order, with the guarantee documented and covered by a regression test.

Escrito por el modelo de indexación a partir del texto del issue.