fix(session): never adopt an undrivable page as the Agent Window home tab

[dangzitou]

What problem this solves

Fixes #129.

ensureActiveTab adopts any tab whose id came from the
chrome.windows.create result, on the assumption that the tab it asked
for (about:blank) is still there. A new-tab hijacker can move that
tab onto its own chrome-extension:// options page before window
initialization runs. The session then bootstraps on a page it can never
drive: DevTools attachment to a foreign extension page fails with
"Cannot access a chrome-extension:// URL of different extension", and
every CDP-backed call on the session target fails afterwards. The
reporter reproduced this with Edge + a hijacking extension; the same
class of failure can hit any browser whenever the creation tab's
content is replaced before the first CDP command.

How this fixes it

Validate the creation tab's URL — and its in-flight pendingUrl —
before adopting it as the session home. chrome://,
chrome-extension://, edge://, brave://, opera://, vivaldi://,
devtools:// and view-source: pages are undrivable, so a fresh
about:blank home tab is created in the Agent Window instead and
activated. The foreign tab is left untouched: it sits inside the
session-owned window, is inert to the session (which only addresses
its home tab), and disappears with the window on session stop — so the
fix never closes or moves a page the user or another extension owns.

chrome:// pages are included even though the interface doc already
noted they reject Page.navigate: the creation tab could be sitting on
chrome://newtab/ when a browser's new-tab override fires.

User impact

Sessions always bootstrap on a drivable home tab, so the first
navigate/snapshot/observe after session start cannot fail with
a cross-extension access error. No behavior change when the creation
tab is healthy, and adoption still happens when the tab's URL is
unknown (no tabs permission).

Validation

• pnpm exec biome check clean on the changed file.
• Extension suite: pnpm ext:test — 2348 passed, 122 skipped, 0 failed
  (no new tests included in this PR).
• Local end-to-end sanity (macOS, Chrome for Testing 154 + unpacked
  extension): session start → navigate https://example.com →
  observe all succeed with the fix loaded. I could not reproduce the
  poisoning itself end-to-end on macOS — the reporter's trigger is
  Edge-specific — so the wrong-tab condition is covered by the existing
  session-manager suite plus the e2e sanity run rather than a
  browser-level repro.