[Bug]: preview_navigate reports a timeout even when the navigation actually completed

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Open a fresh preview tab and navigate it to a simple page, e.g. https://example.com, to confirm the tab is healthy.
2. Call preview_navigate({ tabId, url: "https://en.wikipedia.org/wiki/Main_Page" }) with default options (default readiness: "load", default timeoutMs: 15000).
3. Observe the tool call fail.
4. Immediately call preview_status({ tabId }).
5. Immediately call preview_navigate({ tabId, url: "https://example.com" }) again (back to the simple page) to confirm the tab is still usable.

Expected behavior

Either the navigate call succeeds within the timeout, or, if it genuinely fails/times out, the tab should reflect that the navigation did not happen (previous URL/title, or an error state) — not a fully loaded target page.

Actual behavior

Step 3 failed with:

Preview automation navigate timed out after 15000ms.

But step 4's preview_status, called immediately after, showed the navigation had actually succeeded:

{"available":true,"visible":true,"tabId":"tab_4","url":"https://en.wikipedia.org/wiki/Main_Page","title":"Wikipedia, the free encyclopedia","loading":false, ...}

loading: false and the correct url/title — the page had fully navigated and finished loading. A subsequent preview_snapshot on the same tab succeeded normally and returned the real Wikipedia page content.

So the caller receives a hard failure for an operation that, from every observable signal, actually succeeded. An agent acting on the reported error has no way to know the navigation it just "failed" is sitting there fully loaded — it will likely retry the navigation (wasting a request) or report the target page as unreachable when it isn't.

Re-running the identical navigate call against the same URL/tab immediately afterward (step 5, to a lighter page) returned instantly with no error, so this isn't a broadly broken tab — it looks specific to a single navigation taking longer than the 15s deadline to signal completion back to the caller, likely on pages with many subresources (Wikipedia's main page loads dozens of images; several of its subresource requests failed with net::ERR_CONNECTION_RESET in this sandboxed browser, which may extend how long the default readiness: "load" milestone takes to settle, or to give up, past the fixed timeout).

Impact

Major degradation or frequent failure

Version or commit

T3 Code Nightly 0.0.37-nightly.20260829.1223

Environment

Windows 11 (build 10.0.26200.0), T3 Code Nightly desktop, mcp__t3-code__preview_* tools via a Claude Code agent session.

Related issues

Related to but distinct from #8257: that issue documents preview_snapshot/preview_evaluate/preview_resize sharing a client/server 15s deadline via waitForDesktopOverlay, and explicitly notes preview_navigate "kept working" in that scenario. This report is about preview_navigate itself reporting a timeout failure for a navigation that demonstrably completed — a different code path, since #8257 says navigate isn't gated by the overlay wait.

Workaround

After a navigate call times out, check preview_status before assuming the navigation failed or retrying — the target page may already be loaded.

Start in apps/server by tracing the preview_navigate entry point, its readiness handling, and the 15-second timeout path. Reproduce the sequence with preview_navigate, preview_status, and preview_snapshot, then inspect any existing server tests for navigation timeouts. Done means a completed navigation is not reported as a failed timeout, with regression coverage for this case.