Pup - the AI's own browser

@@ -63,19 +63,34 @@ needs: it outlives a bridge restart, a tab crash, and pup itself.  ### The deterministic birth sequence (the mandated path) -1. **Acquire the birth MUTEX.** Births are serialized, so only ONE window is ever in the off-screen-   birth zone at a time - this is what makes "which new window appeared?" unambiguous, with no-   geometry involved.-2. **Snapshot** the current top-level window set for this profile's Chrome PIDs.-3. **`Target.createTarget` off-screen at a UNIQUE coordinate** (`-32000 - N*64`, N a monotonic-   counter; verify the slot is empty first). Unique coordinate is a backup identifier during the-   off-screen instant; the mutex is the real guarantee.-4. **Capture the hwnd by set-diff** (windows-after minus windows-before). Exactly one new window-   under the mutex. This is a set difference, NOT a geometry match - allowed.-5. **`Browser.setWindowBounds` on-screen within 50ms** of creation (see the 50ms rule below).-6. **`SetProp(hwnd, "AdomPupSid=<sessionId>", 1)`** - the durable tag. Done AFTER the on-screen-   move so it never eats into the 50ms budget.-7. **Release the mutex.** Store the hwnd in the session as the in-memory FAST PATH.+⚠ **UNIQUE OFF-SCREEN COORDINATES DO NOT WORK — do not "fix" birth to use them (corrected 2026-08-22).**+An earlier version of this skill (and claims made to John) said each window is born at a unique+off-screen coord (`-32000 - N*64`) so births can't collide. That was FALSE and was never in the code:+**Windows CLAMPS an off-screen coordinate back on-screen** (`server.js`: "position is unreliable —+Chrome clamps our -32000 birth coord on-screen"), so you cannot identify a window by where it was+born. The code births EVERY window at the SAME `-32000,-32000` and that is correct — the coordinate is+NOT the identity signal.++1. **`Target.createTarget` off-screen at `-32000,-32000`** (fixed; the coord is only to keep the birth+   invisible, it is NOT an identifier — it gets clamped).+2. **Find the new PAGE by the puppeteer page-set diff** (`browser.pages()` before/after). This is+   CDP-level and unambiguous per `createTarget` — you have the right Page object.+3. **`Browser.setWindowBounds` on-screen within 50ms** of creation (see the 50ms rule).+4. **Set a UNIQUE TRANSIENT TITLE on that exact page** — the page is on `about:blank` pre-navigation,+   so `document.title = "PUPBIRTH-<seq>-<rand>"` is yours to set and no other window (pup or native)+   can carry it. Titles are NOT clamped, so this IS a reliable identifier even under concurrency.+5. **Capture the hwnd** = the OS window (of this profile's Chrome PID) whose title contains that unique+   token. Deterministic even when 3 windows open in the same millisecond (v2.0.287 — the fix for the+   set-diff's ">1 new window, REFUSING to guess" collision that randomly left one window unparked ++   un-iconed; John's "insanely inconsistent"). The birth MUTEX still serialises creation, but it does+   NOT prevent windows materialising in the OS enum at the same instant — which is why the set-diff+   raced and the unique title is needed.+6. **`SetProp(hwnd, "AdomPupSid=<sessionId>", 1)`** — the durable tag (on the first resolve that has+   both the sessionId and the hwnd).+7. Store the hwnd in the session as the in-memory FAST PATH.++The set-diff ("windows-after minus windows-before under the mutex") is the OLD birth capture and is+DELETED — it could not disambiguate simultaneous births and refused. Do not bring it back.  ### Re-finding a window (runtime, and after a restart)