Pup - the AI's own browser

@@ -70,19 +70,33 @@ The Mouser case on 2026-08-22 was exactly the second row: `BLANK` thumbnail but because Mouser served a 403 bot-wall - a blank *page*, not a blank *paint*. Do not "fix" rendering for that; it is a sourcing/bot-wall problem. -## The fix this verifies (so nobody regresses it)+## The outcome (2026-08-22): the blank IS left blank, on purpose. Do NOT "fix" it. -`createPageInNewWindow` pulses `Emulation.setFocusEmulationEnabled` ON for two animation frames at-birth, then OFF (v2.0.280 -> made a one-shot in 2.0.281). This is John's "one rAF to get a rendering-to occur": the occluded window composites a single frame (Chrome retains the last frame for an-occluded window, so it stays painted), then returns to throttled/idle. Do **NOT** leave focus-emulation ON, and do **NOT** reach for the highFps anti-throttle LAUNCH flags to solve blankness --both keep the page rendering continuously and reintroduce the issue-#14 battery drain. The whole-point is: paint once, then idle. Re-run this render test after any change to the birth/park/occlusion-path and confirm a freshly-opened background vendor page still scores RENDERED.+The blank occluded-thumbnail is UNAVOIDABLE without a cost John rejected, and every attempt to fix it+was reverted. Recorded so nobody burns days re-deriving this: -## Known limitation / TODO+- **`Emulation.setFocusEmulationEnabled` (tried v2.0.280-284, REVERTED in 2.0.285).** It does make an+  occluded window paint (thumbnail renders), and it CAN be toggled at runtime — but it **ACTIVATES the+  OS window**: it foregrounded a background pup window, the exact focus-steal off-screen birth exists+  to prevent. Do NOT reintroduce it, one-shot pulse or leased.+- **The highFps anti-throttle LAUNCH flags / `--disable-backgrounding-occluded-windows`** keep occluded+  windows painting WITHOUT touching focus, but they are browser-LAUNCH flags: all windows, always, no+  per-window lease possible, and they keep active pages rendering fleet-wide (the issue-#14 battery+  drain). Rejected.+- **A per-window render LEASE** (render for N min after interaction, then throttle) is what John wanted,+  but it needs a per-window RUNTIME render toggle that does NOT foreground — which does not exist+  (focus-emulation is the only runtime toggle and it foregrounds). So the lease is not buildable. -- The birth pulse fixes NEW windows. A window brought back by crash/sleep RECOVERY does not go-  through `createPageInNewWindow`, so it can still come back blank - apply the same one-shot pulse on-  the recovery/re-attach path, then verify with this test.+**John's decision: leave occluded thumbnails blank.** The impact is narrow — it is ONLY the taskbar+HOVER preview. Two things are unaffected:++- **`pup_screenshot` works on background/occluded windows** (CDP `Page.captureScreenshot` renders to an+  OFF-SCREEN buffer, so it returns full content and does NOT foreground — measured 0/101). This is why+  pup's ralph-testing was never broken. It does NOT update the live window surface, so it does not fix+  the thumbnail (measured: occluded thumbnail BLANK before AND after a screenshot).+- **Revealing/foregrounding a window renders it natively** (proven: foregrounded DigiKey painted the+  full page). So opening a pup window shows content; only hovering an occluded one shows blank.++If you are here because a window is blank: use this test to confirm it, then STOP — it is expected for+an occluded window and there is no non-foregrounding, non-battery fix. Only investigate if a window is+blank when FOREGROUNDED (that would be a real bug).