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.

L’issue ne mentionne aucun fichier source, test ou point d’entrée. Commencez par reproduire le problème d’ordre lors d’un appel d’outil de longue durée avec des messages utilisateur et des system_notifications en attente ; c’est terminé lorsque l’ordre de livraison est déterministe ou que chaque élément expose suffisamment de données au moment de sa mise en file d’attente pour établir l’ordre, la garantie étant documentée et couverte par un test de régression.

Rédigé par le modèle d'indexation à partir du texte de l'issue.