Pup - the AI's own browser

@@ -462,27 +462,32 @@ Measured, not asserted. Re-run these before believing any future change to the o | Backstop still works | Stranded a window at `-32000,-32000` (John's exact failure state) | pulled back to `10,10` in 50s (crr) / 85s (AdomLapper) | | No regressions | `tools/selftest.sh` both machines | 13/13 GREEN on AdomLapper and ConfRoomROG | -**Known gap, stated rather than papered over:** on the AdomLapper re-test the `[focus]` handback line-did not appear, so it is not established whether the birth grace alone carried it or the handback-also fired. The OUTCOME was correct either way (foreground unchanged, window bottomed), but if you-are touching this path, resolve that first instead of inheriting my uncertainty.+**RESOLVED (was an open gap; closed 2026-08-20 by measurement, not reasoning).** The question was+whether the birth grace alone carried the ti.com retest or the focus handback also fired, since no+`[focus]` line appeared on AdomLapper. Three measurements settled it: -**The strongest single test (John's, and the one to run first from now on):** open ti.com, mouser.com-and digikey.com **simultaneously, each under a different `owner` / `ADOM_AI_THREAD`**. One pass then-exercises everything that has ever broken here at once:-- three windows born concurrently (the birth lock, R1, R4),-- three DISTINCT thread tiles rather than one grouped button, so per-window identity is visible on-  glass instead of inferred from a log line,-- three different vendor favicons decoded onto the badges — and **ti.com and mouser.com are exactly-  the two that used to render generic globes** (classic BMP/DIB-in-ICO, fixed by `icoLargestDibRgba`-  in 2.0.212), so this doubles as the icon-decode regression test,-- and it stays in the user's chosen `tiles` mode, so nothing about his settings has to be disturbed-  to run it. Do NOT flip `taskbarMode` to `aumid` to get per-window icons; distinct owners is the-  production-realistic shape and leaves the user's mode alone.+1. **Sampled the OS foreground every 100ms across a full window birth on AdomLapper: 82 samples,+   foreground NEVER left John's Edge window (0/82).** No `[focus]` line because there was no steal to+   hand back — not because the handback silently failed.+2. **On ConfRoomROG the steal DOES happen, and the handback DOES restore it** — verified twice, with+   a non-Chrome window holding the foreground (`132154 -> 1639276 -> back to 132154`) and with a pup+   Chrome window holding it (`1639276 -> 15599714 -> back to 1639276`). The handback works.+3. **What differs is USER INPUT RECENCY, and it is Windows protecting the user, not us.** Measured at+   the same moment: AdomLapper `userIdle=15ms` (John actively typing) vs ConfRoomROG+   `userIdle=440344ms` (~7 min, nobody there). Windows' foreground lock denies a background process+   the foreground for `foregroundLockTimeout` following real user input, so **on a machine somebody+   is actually using — the only case that matters — the steal cannot land.** It lands on idle+   machines, where it harms nobody, and the handback puts it back anyway. -Measured 2026-08-20: three buttons, `mouser vendor test` / `ti vendor test` / `digikey vendor test`,-each "1 running window", each wearing its own favicon badge (Mouser blue M, TI red Texas logo,-DigiKey red D). Red-boxed pixel evidence in shotlog channel `pup-window-fix`.+**A wrong theory worth recording so nobody re-derives it:** it is NOT "the foreground process may+reassign the foreground to its own new window". That was the obvious story (both crr steals happened+while a pup Chrome window was frontmost) and Case A above DISPROVES it — Hydrogen, a completely+different process, held the foreground and Chrome still took it. Coarse before/after foreground+sampling cannot see this at all, because the handback restores the value between your two samples;+you must read the `[focus]` log line or sample continuously.++**Both layers are load-bearing, neither is redundant:** the handback fixes the steal when it lands,+and the birth grace (R6) stops a landed steal from being misattributed to the user.  **How to re-verify in one pass:** open a window with a poller running against the OS window list and assert the FIRST sighting is on-screen (not the final position — the final position was always right,