fix(profile): never prompt for a profile when driving a remote browser

Profile selection works by launching the browser with --profile-directory and
letting ProcessSingleton delegate to the running process, which only reaches a
browser on this machine. discoverEndpoint() already withholds userDataDir for a
remote target, but resolveUserDataDir() fell through to the local candidate
dirs, so the picker offered this disk's Chromium profiles for a browser on
another host - on castle, Brave's profiles for a Chrome on :9223. Pinning one
launched a local browser and polled the remote for a sentinel that could never
appear, failing after the seed deadline; seedProfileWindow()'s mismatch guard
missed it because connectedDir is undefined on the remote path.

Setup now returns early instead of prompting - the question had no actionable
answer, and since cancelling stores nothing it returned every session.
/browser-profile and seedProfileWindow() refuse with the reason, the latter
catching a pin left over from a local session.

1 files changed, 40 insertions, 0 deletions

diff --git a/FORK.md b/FORK.md
index 4e78478..68a57bc 100644
--- a/FORK.md
+++ b/FORK.md
@@ -117,6 +117,46 @@ needed at all.
 Note the branch here is `master` (matching the other repos on castle) while
 upstream uses `main`.
 
+## Browser profiles are local-only
+
+Upstream's `/browser-profile` does not work against a remote target, and this
+fork now says so instead of guessing.
+
+Choosing a profile is not a CDP operation. `Target.createTarget` rejects another
+profile's `browserContextId`, and a bare createTarget lands in the focus-derived
+default context, so the only way in is the browser's own command line —
+`--profile-directory`, delegated to the running browser by Chromium's
+ProcessSingleton (`src/profile/launch.ts`). That is a local-process mechanism
+with no remote equivalent.
+
+`discoverEndpoint()` already returns no `userDataDir` for a remote target, but
+`resolveUserDataDir()` used to fall through to `userDataDirCandidates()` — the
+Chromium user-data-dirs on *this* disk. On castle that meant the picker offering
+Brave's profiles while the harness was connected to castle's Chrome on :9223,
+and `seedProfileWindow()` could not catch it: its mismatch guard is
+`connectedDir && connectedDir !== pin.userDataDir`, and `connectedDir` is
+undefined on the remote path. Pinning launched a local Brave window and then
+polled the remote browser for a sentinel that could never appear there, failing
+only after the 15s seed deadline.
+
+So, for a remote target:
+
+- **setup never prompts.** `promptForProfileIfUnset()` returns early. A prompt
+  with no actionable answer is bad enough; because cancelling stores nothing, it
+  also came back every single session.
+- **`/browser-profile` refuses**, naming the target and pointing at
+  `/browser-target local`.
+- **`seedProfileWindow()` refuses**, which catches a pin left over from a local
+  session rather than letting it launch a browser on the wrong machine.
+
+The default against a remote browser is therefore unpinned — whichever window is
+focused. castle's `~/.chrome-cdp-profile` has exactly one profile (`Default`),
+so there is nothing to disambiguate.
+
+Making profiles selectable on castle needs the `--profile-directory` launch to
+happen *on castle*, next to the browser — not a patch to this path, a separate
+piece of machinery. Unbuilt so far.
+
 ## Verifying after a merge
 
 With a browser exposed at `$BU_CDP_HTTP`: