[BUG] Claude in Chrome: phantom/disconnected tab state persists across full Chrome + app restart (macOS desktop app)

## Summary

`claude-in-chrome` MCP tools (`navigate`, `tabs_context_mcp`, `tabs_close_mcp`) report success against a tab that isn't backed by the real Chrome process. The fake state survives a full Chrome quit **and** a full Claude desktop app restart, returning the same stale tab id and page content both times.

This is very likely the same root cause as #79313 ("phantom tabs accept and answer javascript_tool execution after Chrome has closed them"), which was auto-closed as stale rather than fixed. Filing fresh per the stale-bot's own instructions, with a repro on a different platform/interface (macOS + Claude desktop app, vs. the original Windows + CLI report) and a simpler trigger.

## Environment

- macOS (Darwin 25.6.0), Claude desktop app
- Chrome extension "Claude in Chrome" v1.0.93, confirmed enabled in `chrome://extensions` with "On all sites" access
- Single Chrome window/process confirmed throughout (no second profile, channel, or off-screen window)

## Reproduction

1. `tabs_context_mcp {createIfEmpty: true}` → new tab id → `navigate` to a URL. Tool reports success with the correct page title/URL.
2. An OS-level screenshot of the actual Chrome window taken immediately after shows no such tab — just a plain "New Tab".
3. `tabs_close_mcp` on that tab id → tool reports the tab closed. Real Chrome window: unchanged, same tabs still visible.
4. Fully quit Chrome (Cmd+Q) and relaunch it. Separately, fully restarted the Claude desktop app too.
5. `tabs_context_mcp` again → returns the **same tab id**, with the **same stale page title/URL** from before either restart.

Real Chrome tab ids are not stable across a process restart, so this value cannot be coming from the live browser — the extension/session is driving some other, persistent, disconnected browser context.

## Evidence ruling out a wrong-window mixup

Used a separate OS-automation tool (independent of Claude-in-Chrome) to:
- Enumerate all Chrome windows (`app_list_windows` equivalent) — exactly one window found, matching what's on screen.
- Take a full-desktop screenshot — confirmed only one Chrome window exists anywhere on the display, no minimized/off-screen/other-Space window.
- List running apps — only one Chrome process (`com.google.Chrome`, stable channel), no Canary/Beta/Dev/Chromium also installed.

So this isn't a case of screenshotting the wrong window among several — there is only one real window, and it never reflects what the extension reports doing.

## Expected

`tabs_context_mcp` reflects the real browser's current tab state; a full Chrome restart invalidates any previously-tracked tab id.

## Actual

Tool calls report plausible success indefinitely against a target with no corresponding real tab, and that fake state outlives both a full Chrome restart and a full Claude desktop app restart.

Related: #79313 (closed as stale, not fixed — same symptom, different platform/interface, harder-to-hit trigger).

Start by reproducing the issue with tabs_context_mcp, navigate, and tabs_close_mcp while comparing their results with the OS-level Chrome window. Check behavior after fully restarting Chrome and the Claude desktop app, using related issue #79313 for context. Done means the tools reflect the real Chrome tabs and invalidate old tab ids after a browser restart.

Written by the indexing model from the issue text.