observe/snapshot/navigate fail with "Cannot access a chrome-extension:// URL of different extension" when Agent Window tab is born on an extension options page

Bug: observe/snapshot/navigate fail with "Cannot access a chrome-extension:// URL of different extension" when the Agent Window's initial tab is born on ANY chrome-extension:// page

Environment

• OS: Windows 11
• Browsers: Edge 151 AND Chrome 151 (both reproduce; Chrome extension build from Web Store)
• bsk CLI: 0.1.10, daemon protocol 1.0
• BrowserSkill extension: 0.1.6
• Trigger: the Agent Window's initial tab is born on a chrome-extension:// page (e.g. an extension that opens its options page on startup — identified as "Save In" v4.1.0 in our case; on Edge a new-tab hijacker). Reproduces on both Edge and Chrome.

What happened

1. bsk session start succeeds (Agent Window opens).
2. Any CDP-backed operation against the session's tab fails with:

   Cannot access a chrome-extension:// URL of different extension
   

   Affected: observe, snapshot, navigate (all wait-until phases incl. commit/load), press, and presumably click/fill.
3. Evidence that navigation itself SUCCEEDED: tab list shows the tab loaded at the target URL with the right title (e.g. https://news.ycombinator.com, "Hacker News", active=true). Only the CDP attachment / completion-signal path is broken.
4. Once the error starts, it STICKS: even brand-new tabs created with tab create --url <normal-url> (which show the correct URL and title in tab list) keep failing. The DevTools target pointer appears poisoned for the whole session/window.
5. Also reproduced: navigate --wait-until load times out after 30s with "tool RPC timed out" even though the page fully loaded (same root cause — completion signal lost).

Workarounds found

• bsk daemon stop; bsk daemon start clears the stuck state completely (extension reconnects in ~2s). After a daemon restart, the FIRST observe on a freshly created tab succeeded once (@vom 1 / RootWebArea), then the error returned on subsequent calls.
• Creating tabs born directly on a normal URL (tab create --url ...) instead of letting them start at the (hijacked) new-tab page reduces the chance of hitting it.
• screenshot uses a different channel and works reliably even while observe/snapshot fail.

Hypothesis

When the Agent Window's initial tab is born on a chrome-extension:// page owned by ANOTHER extension (because that extension hijacked the Edge new-tab page), the CDP session attaches to that protected target, and every subsequent operation keeps trying to use that poisoned target instead of re-attaching to the current, normal page. CDP cannot access other extensions' pages by design — but bsk should detect this and re-attach to the actual active tab.

Repro

1. Edge with a new-tab-hijacking extension installed (many popular Chinese extensions do this).
2. bsk session start → bsk navigate https://example.com → fails with the error above.
3. bsk daemon stop && bsk daemon start → first observe may work → error returns.

Thanks for the great tool — the Agent Window + real-login-session model is exactly what we needed.

Reproduce with bsk session start, bsk navigate, bsk observe, and bsk tab list when the initial tab is a foreign chrome-extension:// page. Trace the CDP attachment and navigation completion-signal path, including daemon restart behavior. Done means observe, snapshot, navigate, press, and newly created normal tabs work without the cross-extension error or false timeout.