Pup - the AI's own browser

@@ -767,3 +767,38 @@ Rules: - PowerShell reliability on user boxes is NOT a given. `powershell -File` can drop to an interactive   banner (profile damage) and burn its whole timeout. For process queries prefer AD's `process_list`   verb or `cmd /c` one-liners; keep PS for things only PS can do, always async, always with a timeout.++## ⛔ The jump-list "blip" (flyout shows ~200-300ms then vanishes) — UNRESOLVED, do NOT re-derive++**Symptom:** right-click a pup window's taskbar button, the jump list appears for ~200-300ms and+disappears. A second right-click works and stays. Reproduces on EVERY pup window, every time, from a+clean slate. The list CONTENT is correct when shown, and the tasks run.++**Status: not fixed. Tracked on `adom/adom-desktop#40`** (AD owns `desktop_set_window_identity` and the+shell interaction). Four separate pup-side fixes were attempted and all failed. Before you "fix" this,+read the eliminations — three of them cost a release each, and two of them I announced as fixes before+verifying, which was wrong.++| Hypothesis | How it was eliminated |+|---|---|+| Something pup does races the click | Captured the bridge log, waited **40s idle**, captured again: **0 new lines**. pup is silent while the user clicks. |+| AUMID churn recreates the button under the open flyout | Counted registrations per window: windows with **exactly 1** registration (no category flip) blip identically. |+| `shortcut:false` leaves the identity unresolvable | A/B: one window registered with `shortcut:true` (real Start Menu shortcut) vs siblings registry-only → **no behavioural difference** (John tested). |+| Jump list committed before the stamp recreates the button | Shipped a post-stamp re-commit (v1.9.112), verified 1 registration + 1 re-commit per window in the log → **all three fresh windows still blipped**. |++**What is left, and why pup cannot test it:** the per-window AUMID retag itself recreates the taskbar+button, and the shell's first flyout on the recreated button is dismissed. pup cannot avoid the retag (it+is the only way to brand a borrowed Chrome window) and cannot see what the shell does after.++**The decisive diagnostic, for whoever picks it up:** AD flips its OWN window's AUMID for the+embedded/standalone mode signal. Right-click **AD's own** taskbar button after a mode flip. If AD's own+flyout blips too, this is inherent to runtime AUMID retagging and reproduces with no bridge involved.++**Two process lessons, worth more than the bug:**+1. **Eliminate with measurement, not with a fix.** Each of the first three attempts was plausible,+   shipped, and wrong. The measurements (idle log diff, registrations-per-window, the A/B) are what+   actually narrowed it, and each took minutes.+2. **A user's "it seems ok now" is not a pass.** Mid-investigation John said the right-click was fine;+   it turned out he was clicking windows he had *already* right-clicked once (warm), while fresh windows+   all failed. Ask WHICH instance was tested before believing a fix, and prefer a freshly created+   subject.