[Feature]: Support in-round queued events — inject user messages arriving mid-tool-execution into the current trajectory

## Summary

QwenPaw currently processes user messages strictly between rounds: a message sent
while the agent is mid-tool-execution (e.g. during a long `search_web` call) is
queued and only handled as a brand-new round after the current LLM+tool loop fully
finishes. The agent cannot merge a user's supplementary instruction into the round
that is currently running, wasting latency and token on a redundant extra round.

## Component(s) Affected

- [x] Core / Backend (app, agents, config, providers, utils, local_models)
- [ ] Console (frontend web UI)
- [x] Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
- [ ] Skills
- [ ] CLI
- [ ] Documentation (website)
- [ ] Tests
- [ ] CI/CD
- [ ] Scripts / Deploy

## Problem / Motivation

The LLM training paradigm is synchronous: after the model emits a tool call, the
next message must be the tool result. Real deployments are asynchronous: the user
may send a refinement ("only look at the last month", "stop, I meant the other
account") while the tool is still executing.

Today (`app/channels/unified_queue_manager.py`) messages are queued with priority,
but consumers serialize them: each user message starts a full new round. There is
no "in-round injection" — i.e. when a tool.result returns, the queue is checked and
all pending events are batch-appended to the **current** trajectory so the LLM
processes them in one combined step.

This is the "Queued" strategy from event-driven agent design: a non-urgent event
arriving during tool execution should be batch-appended to the current trajectory
at the next safe point (a tool return), rather than deferred to a whole new round.

## Proposed Solution

In the per-session consumer loop of `UnifiedQueueManager` (or the request runtime),
after a tool call completes:

1. Peek the queue for pending user messages that arrived while the tool was running.
2. If any exist, append `tool.result` **and** the queued user messages together to
the current trajectory.
3. Let the LLM process the merged context in a single reasoning step.

The injection must be clearly labeled by source (tool result vs. user message) to
avoid prompt-injection confusion, and priority rules should still apply: urgent
events (user.interrupt) keep using the existing cancel path.

## Alternatives Considered

- **Current behavior (do nothing):** simple and safe, but wastes a full round and
latency whenever a user refines a request mid-execution.
- **Cancellation-based handling:** appropriate only for urgent interrupts, not for
routine refinements.
- **Parallel handling:** overkill and confusing for refinements of the *current*
task.

## Additional Context

The LLM-sync / deployment-async gap is the fundamental motivation: real-world
asynchronous users expect their mid-task refinements to be merged efficiently,
not deferred to a full extra round.

## Willing to Contribute

- [ ] I am willing to open a PR for this feature (after discussion).