Pup - the AI's own browser

@@ -500,6 +500,45 @@ from the user's browser.** the user" and for auth when abe isn't warranted. Steering between these belongs in pup's hints and the pup/abe skills — the calling AI can only pick the right surface if the surfaces say who they are. +## Full icon/identity takeover (option 3) — prototype findings 2026-07-18 (do NOT re-derive)++Goal: pup windows should read "Adom Pup" with the Adom icon EVERYWHERE (taskbar, alt-tab, pins) —+no Chrome logo, no CfT "Test" icon. Prototyped live on AdomLapper; every mechanic below verified.++**What works, and the resolution chain:**+- **AUMID stamp**: `SHGetPropertyStoreForWindow` + set `System.AppUserModel.ID`+  ({9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3},5, VT_LPWSTR) = works cross-process, persists on the+  window. Gives pup windows their own taskbar grouping identity ("Adom.Pup").+- **Taskbar button icon**: `WM_SETICON` (big+small) takes effect immediately.+- **Alt-tab**: resolves through the AUMID → a REGISTERED Start Menu .lnk carrying the same AUMID+  (icon + display name). An unregistered AUMID falls back to the exe resource (the CfT "Test"+  icon). Registration is read at WINDOW CREATION and cached by Explorer's AppResolver —+  register BEFORE any window exists (install time), and know that a just-created .lnk needs an+  Explorer restart to be seen (prototype confirmed: even fresh windows + explorer bounce weren't+  enough alone — see the handle lesson below, which contaminated that test).+- **Pinning trap SOLVED**: point the registered .lnk at `adom-desktop-cli.exe browser_open_window+  {...}` — a pinned "Adom Pup" then launches a REAL managed pup window through the bridge instead+  of a bare orphan CfT.++**THE HARD LESSON — icon handles are process-owned:** `LoadImage`d HICONs are USER objects that+DIE when the loading process exits. A transient script (or any short-lived helper) that stamps+`WM_SETICON` leaves the window pointing at a DEAD handle moments later — the taskbar may render+once before death, then every later read (alt-tab!) falls back to the exe icon. Probe evidence:+`WM_GETICON` returned a different handle after every script run. Also `SetClassLongPtr(GCLP_HICON)`+FAILS silently cross-process (returns 0; class data lives in the target process). Consequence:+**the icon stamping MUST be done by a long-lived native process that owns the HICONs for the+windows' whole lifetime — i.e. AD-core.** This is not just the ownership doctrine, it is a+mechanical requirement.++**The production design (AD feature request):**+1. AD installer registers the "Adom Pup" Start Menu .lnk (AUMID `Adom.Pup`, adom-pup.ico, target =+   adom-desktop-cli browser_open_window) — warm AppResolver cache before any window ever exists.+2. New AD verb `desktop_set_window_identity {hwnd|titleContains, appId, iconPath}`: AD loads the+   .ico ONCE (handles live as long as AD runs), stamps the AUMID property + WM_SETICON per window.+3. pup calls it at park time, same place as the badge; overlay badge retired for pup windows+   (kept for explicit branded `browser_use` pins, where the base icon is genuinely Chrome/Edge).+Rejected: patching CfT's exe icon resource (breaks signature/sha validation, SmartScreen/AV risk).+ ## The foreground gate (v1.8.70) — abe-parity dual key, and the AD interception hole  Foregrounding (open `foreground:true`, `browser_raise_os_window`, `browser_focus_window`) requires a