fix(tour): an unanswered tour bridge no longer costs 45s per action

[OutThisLife]

Fast follow on #89620. A user trying to reproduce the tour demo reported the model timing out on tour.

What's wrong

tour is a blocking bridge: Python emits tour.request and waits up to 45s for the renderer to answer tour.respond. The handler that answers ships in the desktop bundle; the tool is offered by the backend. Those update on different clocks.

Against a desktop build older than the tour tool, the event lands in a renderer with no branch for it. Nothing answers, and the agent blocks the full 45s — once per action the model tries. Because the schema (correctly) tells the model to call action='targets' first and then narrate, one "give me a tour" turn stacks those waits:

targets  45s  →  show  45s  →  show  45s  →  show  45s  →  stop  45s

Roughly four minutes of dead air, ending in "The tour request timed out, or no GUI window answered." Nothing in the system noticed that the client provably could not answer the first one.

This is not limited to old builds — a renderer that crashed or a window that went away fails the same way.

The fix

Hold a session's first tour action to a deadline a working renderer cannot miss, and let an unanswered probe mark the bridge unavailable for that session. Later calls then return immediately with an error naming the actual fix, instead of stalling again.

Once a client has answered once, real actions get the full deadline back, so a preview tour injecting its engine into a live page still works, and a single slow action no longer condemns a live client. The verdict lives on the session record, so it dies with the session and a new one re-probes.

Measured on the five-action sequence above: ~225s of dead air becomes a single 10s probe, then instant.

targets   10.0s  {"success": false, "error": "No Hermes Desktop window answered ...
show       0.0s  {"success": false, ...
show       0.0s  {"success": false, ...
show       0.0s  {"success": false, ...
stop       0.0s  {"success": false, ...

What this deliberately does not do

It does not stop the tool being offered to a client that can't run it. Hiding it needs a capability the client declares at session.create, and since prompt caching fixes the toolset for the life of a conversation, that can only ever take effect for a new session. It would not have helped the reported session, and it cannot help a renderer that dies mid-conversation — which is why the in-session behaviour is the part worth fixing first. Happy to follow up with the handshake if we want the tool gone entirely for older apps.

Tests

tour shipped without any, so this adds both halves:

• tests/tools/test_tour_tool.py — the tool's own contract (toolset placement, action/surface/step validation, payload shape, JSON pass-through, callback failure).
• tests/tui_gateway/test_tour_bridge_fail_fast.py — the bridge: first action probes, an answering client gets the full deadline back, an unanswered probe explains the real problem, later actions short-circuit, a proven client survives one slow action, a new session re-probes.

scripts/run_tests.sh tests/tui_gateway/ tests/tools/ — tests/tui_gateway/ fully green. The tests/tools/ failures (daytona, voice, web_tools_config, file_tools) reproduce identically on clean main with the same counts; they're missing optional deps in my local env.