Pup - the AI's own browser

@@ -249,9 +249,17 @@ The full background open sequence (`tryDetachedLaunch` + `osBackgroundWatchdog`) 1. Spawn with `--no-startup-window --window-position=-32000,-32000` (no `--start-maximized`). 2. Connect CDP; `newPage()` creates the window (off-screen, unfocused — the OS denied foreground). 3. ONE hidden-PS park: wait for the window to EXIST (EnumWindows @50ms, pid-list refresh only every-   500ms — refreshing every tick blew the process budget under parallel opens), hand focus back IF-   somehow taken (normally a no-op), `SetWindowPos(HWND_BOTTOM, 0,0,scrW,scrH, SWP_NOACTIVATE)`,-   self-verify, EXIT. The open response awaits this verdict (`background: backgrounded`).+   500ms — refreshing every tick blew the process budget under parallel opens), then:+   - **Launch-gap escape hatch (v1.8.52):** FIRST check `GetForegroundWindow() == pup`. Because+     `--no-startup-window` means Chrome cannot raise itself, pup-foreground has exactly ONE possible+     cause: **the user clicked the taskbar button during the launch gap** (while the window was still+     at its off-screen coords, where activating it shows NOTHING — that was the "first 2 seconds the+     click does nothing" bug). In that case: `SetWindowPos(HWND_TOP, 0,0,scrW,scrH, SWP_SHOWWINDOW)`,+     leave the user's focus on it, report `user-foreground`, exit. This check is only valid BECAUSE+     of the launch flag — without it, pup-foreground is ambiguous and every heuristic fails (see+     dead ends).+   - Otherwise: `SetWindowPos(HWND_BOTTOM, 0,0,scrW,scrH, SWP_NOACTIVATE)`, self-verify, report+     `backgrounded`, EXIT. The open response awaits this verdict. 4. Nothing ever re-parks. `foreground:true` opens skip all of this and launch maximized on-screen.  **The 4 techniques (still true, now mostly belt-and-suspenders):**