Pup - the AI's own browser

@@ -540,3 +540,54 @@ accent), not red, so the bar reads as "working" and NOT as "error". Verified by shows a sweeping blue marquee segment, the second a blue bar with a grey remainder. Do not assume a progress bar means failure just because an early frame looked reddish, that maroon button tint is the pre-existing AUTO-FLASH attention state (scheduleAutoFlash fires on mutating verbs), not progress.++## RESOLVED: the jump-list header icon had TWO causes, one of them ours (AD 1.9.153 / pup 1.9.58)++AD found the first and it was NOT either hypothesis we filed:+- `RelaunchIconResource` was being written as `<path>\icon.ico,0`. The trailing `,0` is the+  PE-MODULE icon-location form (`<exe-or-dll>,<index>`). A standalone `.ico` has no indexed+  resources, so the shell's classic parser fails and falls back to the generic white document — but+  ONLY on the jump-list header, because the taskbar button + Alt-Tab resolve through the AUMID+  registry IconUri (a plain image), not the per-window RelaunchIconResource. That asymmetry is+  exactly why the button was branded and the header was not. Fixed AD-side; AD now emits a BARE path+  for a `.ico` and `,<index>` only for a real `.exe`/`.dll`. Nothing changes in our calls.+- It was NOT baked-at-button-creation, and the shell CAN load a standalone `.ico` for the header.++**The second cause was OURS.** Every `pup-cat-*9.ico` I built had its 256x256 entry stored as an+uncompressed BMP/DIB. Since Vista, a 256px `.ico` entry MUST be PNG-compressed or the shell renders+the generic white document. My hand-rolled ICO packer wrote BMP for every frame. Confirmed by AD's+new `iconCheck`:++    ok: false+    "the 256x256 entry is stored as an uncompressed BMP/DIB, not PNG ... or the jump-list+     header + taskbar render the GENERIC WHITE-DOCUMENT icon."++Rebuilt all six from their SVGs with **BMP for 16/24/32/48/64 and PNG for 128/256**; all six now+report `iconCheck.ok: true, issues: NONE`. `PUP_ICON_GEN` bumped to `i3` so every button is recreated+against the fixed art.++**Use `iconCheck` from now on.** `desktop_set_window_identity`, `desktop_register_app_identity` and+`desktop_set_window_jumplist` (with `headerIcon`) return `{kind, sizes, issues, ok, hint}`. It catches+the 256-BMP trap, SVG (the Win32 shell cannot load it), a `.ico` with no small size, and an `.exe`+passed where an image is wanted. Check `ok` before shipping an icon instead of shipping and squinting.++## Thumbnail tooltip (AD >= 1.9.152: `desktop_taskbar { thumbnailTooltip }`)++The hover-preview caption is the window title and truncates at ~25-30 chars. The tooltip is the only+UNCAPPED text surface on that popup and it accepts NEWLINES, so it carries the real answer to "what+is this window?":++    Adom Pup · Adom wiki (SIGNED IN)+    wiki.adom.inc/adom/bmv080+    Chrome for Testing · 1 tab++`mixed` names the distinct hosts so the user can see WHY it is mixed without opening it. Pass `""` to+clear back to the title. Companion `thumbnailClip: {x,y,w,h} | null` crops the LIVE preview to a+region.++**Wiring gotcha that cost a release:** the tooltip was first hooked only into `refreshWindowChrome`+(drag-out / reclaim / relaunch) and the category-change hook. The NORMAL OPEN PATH calls+`brandPupWindow` directly and touches neither, so a freshly opened window never got a tooltip and the+log was silent. It now lives in `updateTabCountBadge`, which already runs on open AND on every tab+open/close — exactly when the tooltip's content (category + tab count) changes. When adding per-window+taskbar state, hook the function that runs on OPEN, not just the repair paths.