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)

Run the three-iteration repro in examples/agents/79_agent_message_bus.py, then inspect the /api/agent/{id}/stop and /api/workflow/{id} responses alongside server logs for a failing run. Done means the stop request reliably sets _stop_requested to true and the agent exits its loop instead of timing out on join(timeout=30).

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