fix(computer_use): reconnect a dead cua-driver session instead of hanging (#55048)

[teknium1]

Summary

Fixes the session-hang half of #55048 (Bug 1): a dropped cua-driver MCP connection left the wrapper wedged so every later list_apps/capture hung forever instead of reconnecting.

Root cause

_CuaDriverSession._lifecycle_coro owns the MCP contexts and, on exit, cleared _session but never reset _started. So after a driver crash / connection drop, _started stayed True: _require_started() passed, and the call then operated on a None session — a permanent hang from the first MCP blip.

Changes

• _lifecycle_coro's finally now sets _started = False on any exit, so a dead session is re-enterable. Idempotent no-op on the normal stop() path (which already set it false); a plain-bool write is atomic in CPython, so it's safe from the bridge-loop thread without taking the lock stop() may hold.
• call_tool() re-enters start() when the session isn't active, rebuilding it before the call. The start_session/end_session handshake — driven by start()/stop() themselves while _started is in flux — is exempted so bootstrap doesn't recurse.

Scope note

This is Bug 1 of #55048. Bug 2 of that issue (expose a foreground dispatch param so clicks land on Qt/Electron) already shipped as the delivery_mode work in #67123 — this PR is only the lifecycle-reconnect fix.

Validation

	Result
New tests (test_computer_use_delivery_ladder.py)	finally resets _started; call_tool restarts a dead session exactly once
Full computer_use suite	233/233
ruff + Windows-footgun	clean

Infographic