Pup - the AI's own browser

@@ -1154,3 +1154,43 @@ verification) and the docs/pkg half is silent. Nothing fails when the skill is s checklist item and a gate (`ship.sh` GATE 2b now checks the pkg tarball resolves at the shipped version), not a good intention. I wrote the release-vs-pkg trap into this very skill in the morning and still walked into it in the afternoon, which is the argument for enforcement over knowledge.++## ⛔ Verify the path that ALREADY WORKED, not just the thing you built (2026-07-25, the worst regression of the day)++I added caller-identity forwarding to pup's AD callbacks (v1.9.104), verified the new behavior (delegate+headers reached AD, attribution rendered), and shipped. What I did NOT verify is whether windows still+**branded and appeared**. They did not. AD (>=1.9.183) **refuses any command with no caller identity**,+and I had deliberately sent nothing when pup acted on its own behalf, reasoning that "no caller" was the+honest answer. AD's answer to no caller is a refusal, so EVERY `desktop_*` call from the bridge was+rejected. One cause, two user-visible failures:++- `desktop_set_window_identity` refused → **no branding**: five example windows all fell back to+  Chrome's generic icon, including OTHER threads' windows. I broke it fleet-wide, not just for myself.+- the on-screen park refused → windows **stranded at -32768,-32768**, so clicking their taskbar button+  showed nothing at all. John's words: "i can't even click these icons to open the window?"++The contract I had just read says, verbatim, *"send your own caller block when the work is genuinely your+own."* I read that and implemented the opposite.++**The fix:** `adCommand` ALWAYS identifies a caller — the forwarded thread when there is one, else+`pup bridge (self)` — sent as BOTH a header and an args `caller` block, because AD's precedence puts args+above headers and a header-only path had already regressed once the same day.++**THE RULE, and it is the highest-value line in this skill:** when you touch a SHARED CALL PATH+(`adCommand`, `sendJSON`, a resolver, a response composer), a passing test of your new feature proves+nothing about what you broke. **Open a pup window and confirm it is BRANDED and ON-SCREEN.** That one+observation exercises identity registration, the window stamp, the jump list and the placement park in a+single shot, and it is the cheapest possible regression net for this bridge:++```bash+adom-desktop --target <box> --ai-thread "<you>" browser_open_window '{"sessionId":"smoke","url":"https://example.com"}'+adom-desktop --target <box> --ai-thread "<you>" bridge_log_read '{"name":"puppeteer","lines":40}'   # expect "stamped appId=", NOT "stamp FAILED"+adom-desktop --target <box> --ai-thread "<you>" desktop_find_window '{"titleContains":"session: smoke"}'  # rect.left must NOT be ~-32768+```++`stamp FAILED` in the log and a `rect.left` of -32768 are the two tells. Both are one call away and both+were sitting there the whole time I was telling John the feature worked.++**Rescue procedure** if windows are already stranded: a CLI call carries identity, so it is accepted even+while the bridge's own calls are refused —+`desktop_set_window_state {hwnd, state:"restore"}` then `{state:"maximize"}` per window.