Pup - the AI's own browser

@@ -424,3 +424,27 @@ re-commit theirs within seconds.   height=2H for the XOR bitmap + 1bpp AND mask, BGRA bottom-up). `icotool`/`convert` are also present. - Verify a task's committed icon+description by reading the CustomDestinations file (both are   plaintext UTF-16); the TITLE lives in a serialized property-store blob and is not plainly greppable.++## Jump-list HEADER row shows a generic (white document) icon — and why it's WAI (2026-07-20)++The bottom "app tile" row of a pup window's jump list (the "Adom Pup" line with Pin to taskbar /+Close window) renders a generic white-document icon, even though the taskbar BUTTON and Alt-Tab show+the correct category icon. Confirmed on John's box:+- registry `HKCU\...\AppUserModelId\Adom.Pup.<sid>.<cat>.i2\IconResource = ...pup-cat-<cat>9.ico,0`+  (correct — this is what brands the taskbar button).+- The header row's icon is NOT sourced from that. Windows resolves the pinnable app-tile icon from a+  **Start Menu shortcut** that declares the AUMID. Pup registers per-session AUMIDs with+  `shortcut:false` (AD docs: "registry-only, no Start Menu entry — the mode for TRANSIENT per-session+  appIds ... zero Start Menu spam"). No shortcut ⇒ the header falls back to the generic doc icon.++This is a genuine tradeoff, not a fixable bug in the bridge:+- Branding the header needs `shortcut:true` per session ⇒ one "Adom Pup" Start Menu entry PER OPEN+  WINDOW (8 windows = 8 entries). Not worth it. John chose to leave the header generic (2026-07-20).+- The right fix is AD-side: let the jump-list header read the AUMID's registry `IconResource` (or+  accept a header-icon param) for `shortcut:false` registrations. Filed as an AD request.++IMPORTANT testing limitation this exposed: the live right-click jump-list menu (its header icon, and+how each row actually renders) is drawn by Explorer on right-click and is NOT in any file/registry the+bridge can read. The taskbar button, the registry AUMID, and the CustomDestinations task definitions+ARE inspectable; the rendered menu is NOT. Do not claim the menu "looks right" — verify what's+inspectable, and say plainly that the rendered menu needs the user's eyes.