Tool results lost to agent + same command re-dispatched after write_file (triggers doom-loop protection) on 2.2.0-beta.1

## Environment
- QwenPaw 2.2.0b1 (Desktop / Tauri built-in backend), Windows 10, console session
- Upgraded 2.1.0 -> 2.2.0-beta.1 on 2026-08-27; stalls first noticed after the upgrade (not observed on 2.1.x, pending further confirmation)

## Symptoms (5 stalls in a single session, 2 distinct mechanisms)

**Type A — turn terminates right after write_file (3 times)**
The agent writes a script with `write_file`, then the turn ends without executing the
follow-up command. The next step only happens after the user prompts again.

**Type B — same command re-dispatched 6~10+ times -> doom-loop protection fires (2 times)**
After writing a script, the identical `execute_shell_command` call was submitted 6 and
then 10+ consecutive times. Console showed:
`Doom loop: agent stuck after 6 consecutive repetitions`
Repetition Protection (after 6 identical actions -> Pause & Ask) halted the agent.

## Key evidence (why this looks framework-level)

The re-dispatched executions are **completely absent from the agent's conversation
context** — the agent has no memory of issuing them and never received their results.
The results WERE produced (the script printed `HTTP 200 ... RESULT: PASS`, visible in
the console tool-result panel), but the agent only learned of the success when the user
pasted a screenshot of it.

This suggests the tool-result -> agent-context return path drops results after
`write_file`, and the pending call gets re-dispatched by the runtime until doom-loop
protection intervenes.

## Reproduction
Intermittent but frequent: in one session, 3/3 long `write_file` calls were followed by
a stall; 2 attempts to `write_file` + `execute_shell_command` a diagnostic script
triggered doom-loop re-dispatch loops.

## Expected behavior
- Tool results are reliably returned to the agent context after `write_file`
- The runtime does not re-dispatch the same tool call on its own; doom-loop protection
should not be triggered by runtime-level re-dispatches the agent never initiated

## Workaround in use
Prefer single-line inline commands; after a necessary `write_file`, announce the next
step in the same turn so the user knows a stall is a framework issue.