Claude in Chrome: list_connected_browsers reports a live local browser with no browser running, and navigate returns success while doing nothing

**Product:** Claude in Chrome extension (`1.0.92`), driven from Claude Code via
`mcp__claude-in-chrome__*`. Windows 11, Microsoft Edge (stable), single install, single
profile, one extension.

### Summary

With **no browser process running at all**, `list_connected_browsers` continues to report a
connected browser with `isLocal: true` and a `connectedAt` that keeps advancing. Calling
`navigate` against that registration returns `"Navigated to "` **with a real tab id**
and does nothing. No tab, no window, no error. Every subsequent browser call behaves as
though it is driving a real page.

This is not the stale-name/caching problem in #78096 — the entry is not merely
mislabelled, there is no browser behind it.

### Reproduction

1. Close every browser. Confirm independently that none is running — on Windows,
`Get-Process` shows no `msedge`/`chrome`; a UI-Automation enumeration of top-level
windows shows no browser window.
2. Call `list_connected_browsers`.
→ returns one entry, `isLocal: true`, with a recent `connectedAt`.
3. Call `navigate` with any URL.
→ returns `Navigated to ` plus a tab id. Nothing opens.
4. Open the browser. Call `list_connected_browsers` again.
→ **byte-identical** entry, same `connectedAt`. Launching a real browser does not
change the registration.
5. Call `switch_browser`.
→ `"No other browsers available to switch to."` — i.e. the live extension is not
connected, while the dead registration continues to be served as the connected one.

Reconnecting the extension by hand (from its toolbar button) does refresh `connectedAt`,
and one `navigate` then works correctly.

### Observed data

```
no browser process running:
list_connected_browsers -> [{ deviceId: 9c9…, name: "Browser 1",
osPlatform: "Windows",
connectedAt: 1789165039624, isLocal: true }]
navigate -> "Navigated to https://news.ycombinator.com/item?id=…"
tabId 410375950
actual browser windows -> none

after launching the browser (no other action):
list_connected_browsers -> identical, connectedAt unchanged (1789165039624)
switch_browser -> "No other browsers available to switch to."
```

### Two things that make this expensive in practice

**1. There is no in-band way to tell a real success from a false one.** We tested the
obvious candidate: `navigate`'s reply contains two tab-state blocks, and on failures they
disagree. They also disagree on calls that provably succeeded — the second block is
pre-call state by documented design (`tabs_context_mcp` is run for you *before* the
navigation and its result appended). So the disagreement fires on every successful call
too. Nothing inside a successful payload distinguishes it from a lying one; the only
reliable check is an out-of-band one, e.g. reading the browser window's address bar
through the OS accessibility API.

**2. The failure does not stay silent — it produces a confident wrong diagnosis.** After a
`navigate` that went nowhere, `get_page_text` on the returned tab id did not error; it hung
for 45 seconds on `document_idle`, twice. The natural reading is "that website is slow",
and that is what we concluded, wrongly, about an unrelated third-party site. So the first
symptom is a false success and the second is a plausible failure attributed to the wrong
cause.

### Recurrence

The reconnection is not durable. After a manual reconnect, one `navigate` succeeded; **~90
minutes later the same silent failure returned** across two independent sessions
simultaneously. The extension directory on disk had been rewritten in the interval, which
is consistent with an extension update dropping the connection without the registration
noticing — offered as correlation, not proven cause.

### Expected

- `list_connected_browsers` should not report a browser that has no running process, or
should carry a field distinguishing "registered" from "currently reachable".
- `navigate` (and other page-acting tools) should fail loudly when the target extension is
not reachable, rather than returning a success string and a tab id.
- Ideally `switch_browser` returning "no browsers available" and `list_connected_browsers`
returning one should not be able to disagree, since they are answering the same question.

### Environment

- Claude in Chrome extension 1.0.92 (1.0.91 also present on disk)
- Windows 11, Microsoft Edge stable, one install, one profile
- Claude Code desktop 2.1.260

No source file or test is named. Start by tracing the mcp__claude-in-chrome__* entry points, especially list_connected_browsers, navigate, switch_browser, get_page_text, and tabs_context_mcp; reproduce with no Edge process and compare their registration and reachability results. Done means unreachable registrations are not presented as live and page-acting tools return an explicit failure instead of a successful tab id.

Escrita pelo modelo de indexação a partir do texto da issue.