fix(daemon): let navigation timeout results outlive the transport deadline

[lyingbug]

Problem

navigate, navigate_back, navigate_forward, reload and wait_for_navigation do not fail when their lifecycle wait expires. They resolve with a successful result — reached: "timeout", the final_url the page actually reached, and an error_text naming the last observed lifecycle — so the agent can tell a slow page from a stuck one and decide whether to wait, retry or report.

tool_dispatch_transport_timeout gives those methods a transport deadline equal to the operation's own timeout_ms, and the two defaults coincide: DEFAULT_NAV_TIMEOUT_MS in the extension and DEFAULT_TOOL_TIMEOUT in the daemon are both 30s. The extension's reply is therefore due at the exact instant the daemon's deadline fires, and still has to cross the socket afterwards. When the deadline wins, wait_for_dispatch takes WaitOutcome::TimedOutAfterResponse, which preserves a completed Ok only for session_stop, tab_borrow, request_help and the effect-aware transfers. Navigation falls through to the final arm, so the caller receives a bare tool RPC timed out after 30s and the structured outcome the extension had already produced is discarded.

upload, download and request_help own their deadline the same way and are already granted EXTENSION_RESPONSE_GRACE for exactly this reason.

Change

Add the five navigation methods to that grace, and widen the constant's comment now that it covers more than the upload transaction.

These five are the complete set of tools whose extension handler resolves with reached: "timeout" at a caller-supplied deadline (tools/navigation.ts for navigate / back / forward / reload, tools/waits.ts for wait_for_navigation). Every other tool either rejects on timeout or has no caller-supplied deadline, and extension_response_grace_does_not_change_other_tools still pins click to the raw timeout_ms.

If you would rather keep the deadline at timeout_ms and instead extend the TimedOutAfterResponse preserve list in queue.rs to navigation results, I am happy to switch. The grace seemed closer to the precedent already in this function.

Validation

• cargo test --workspace --locked passes, including the two assertions above.
• cargo fmt --all -- --check and cargo clippy --workspace --all-targets --locked -- -D warnings pass.
• Negative control: reverting only the matches! arm while keeping the new assertions fails both tests — 30s vs 32s for the default deadline and 60s vs 62s for an explicit timeout_ms: 60000.
• Daemon-only change; no extension, protocol or plugin code is touched, and it is independent of my other pending work.
• Not exercised against a live browser.

Unrelated flakes seen while validating

Worth a separate look, not part of this change: skill_install::harness::tests::skills_dirs_match_harness_spec fails about 1 run in 10 of cargo test -p bsk --lib, at the same rate on unmodified main and on this branch, and never with --test-threads=1. Sibling tests in that binary set and restore HERMES_HOME / KIMI_CODE_HOME while it reads them. I also saw one remote_server::browser_capacity_does_not_block_renewal_or_replacement failure where the spawned server did not write daemon.json inside the 10s readiness window; it did not recur. Happy to file these separately.