handle.stop() intermittently leaves _stop_requested false, agent never exits its loop

`handle.stop()` returns without raising but sometimes `_stop_requested` is never set to `true`.

In `examples/agents/79_agent_message_bus.py` the DoWhile condition is not flipped (1 of 3 runs), the agent stays blocked on `PULL_WORKFLOW_MESSAGES`, and the caller dies on `join(timeout=30)` → `TimeoutError`.

## Repro

```bash
cd examples/agents
for i in 1 2 3; do uv run python 79_agent_message_bus.py; echo "exit=$?"; done
```

On a failing run, take the id from `Writer started: `:

```bash
curl -s "http://localhost:8080/api/workflow/" | jq '.status, .variables._stop_requested'
# RUNNING, false <- stop() did not set the flag

curl -s -X POST "http://localhost:8080/api/agent//stop" -w '%{http_code}\n' # 200
curl -s "http://localhost:8080/api/workflow/" | jq '.variables._stop_requested'
# true <- endpoint works when called by hand
```

Environment: conductor-oss server (agent runtime + WMQ enabled), python-sdk `main`.

## Ruled out

- Endpoint itself — works by hand on the same stuck execution.
- Loop clobbering the flag — per-iteration `SET_VARIABLE` writes only `_last_tool_results` and `_agent_state`.
- `stop()` raising — it returned normally.
- The WMQ unblock message — sent after the flag write, so it can't produce a `false` flag.

Unexplained: why the POST didn't apply despite a 2xx. Server logs for a failing run would settle it.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

运行 examples/agents/79_agent_message_bus.py 中的三次迭代复现，然后结合服务器日志检查一次失败运行中的 /api/agent/{id}/stop 和 /api/workflow/{id} 响应。完成标准是停止请求能够可靠地将 _stop_requested 设置为 true，并且 agent 退出循环，而不是在 join(timeout=30) 上超时。

由索引模型根据 Issue 内容生成。