0.15.39: dedicated pi-chrome automation tab/window isolation (#6)

Stop pi-chrome from hijacking the user's active tab. Page/navigation actions
with no explicit target now route to a dedicated automation window owned by the
calling Pi session (falling back to a dedicated tab if a window can't be made),
instead of overwriting whatever the user has open.

- Session-scoped ownership: Map<sessionKey, target> in the service worker, keyed
  by a sessionKey forwarded from index.ts, so concurrent sessions (one shared
  extension) never fight over a window or close each other's tabs.
- Persistence: ownership mirrored to chrome.storage.session so a service-worker
  restart re-hydrates and reuses the window instead of orphaning it. Cleared on
  full browser restart; restored windows are then left alone (never reclaimed).
- getTabByParams default branch resolves the owned target; tab.activate/close/
  group/ungroup pass createOwnedTarget:false so management never auto-creates a
  throwaway tab or falls back to the user's active tab.
- Session-group integration: the dedicated-window tab still joins this session's
  tab group, in its own window; grouping stays best-effort.
- Lifecycle: cleanup on /chrome revoke and real session end (not /reload);
  fire-and-forget so it never blocks /quit, /reload, or shutdown.
- Tests: new test-suite/unit/automation-target.test.mjs (isolation, reuse,
  concurrency, restart/reconnect re-hydration, guarded tab.*, group integration,
  window->tab fallback, robust cleanup). Docs + CHANGELOG updated.

1 files changed, 9 insertions, 1 deletions

diff --git a/docs/FAQ.md b/docs/FAQ.md
index 3893575..a450a93 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -30,7 +30,15 @@ Chrome control is also locked per Pi session until you run `/chrome authorize`;
 
 ## Can multiple Pi sessions use it at once?
 
-Yes. The first session opens the local bridge; later sessions detect it and pipe their commands through the same bridge. Each Pi session must be authorized with `/chrome authorize` before its chrome_* tools work.
+Yes. The first session opens the local bridge; later sessions detect it and pipe their commands through the same bridge. Each Pi session must be authorized with `/chrome authorize` before its chrome_* tools work. Each session also owns its **own** dedicated automation window (ownership is keyed by session id inside the one extension), so concurrent sessions never navigate into or close each other's tabs.
+
+## Does pi-chrome navigate my current tab?
+
+No. The first chrome_* action that has no explicit target opens a **dedicated automation window** that pi-chrome owns (falling back to a dedicated tab only if a separate window can't be created), and reuses it for the rest of the session. Your existing tabs and windows are never reused or overwritten. Pass `targetId`/`urlIncludes`/`titleIncludes` to deliberately act on a tab you already have open.
+
+The window survives `/reload` and Chrome service-worker restarts because ownership is tracked by id and mirrored to `chrome.storage.session`. It is closed when you run `/chrome revoke` and on real session end (not on `/reload`); cleanup only ever closes that session's own window/tab.
+
+**After a full browser restart**, `chrome.storage.session` is cleared by Chrome. If Chrome's session-restore reopens the old automation window, pi-chrome no longer recognizes it (its tracking is gone), so it is left alone as an ordinary window — pi-chrome will open a fresh dedicated window for the new run rather than reclaim or close the restored one. pi-chrome never closes a window it can't positively identify as its own, so a user window is never at risk.
 
 ## Why ship as an unpacked extension?