Pup - the AI's own browser

Issue #22 (AdityaAngajala) — session ownership is no longer opt-in. His Finding 1: owner was an optional self-asserted string, so the one real session on his machine, driven actively for 43 minutes by another agent, reported owner:null and had no protection at all; the guard that protects a busy window was opt-in and the real session had opted out by omission. The issue named the blocker as 'relayed commands carry no caller identity, so owner can only ever be a self-asserted string' — that blocker is gone: AD 1.9.180+ sends X-Adom-Caller-* and pup already binds _ownerThread from it. Now the advisory owner field is backed by that AUTHENTICATED identity whenever the caller did not declare one, both at session creation and on any later verb, so a session is owned from birth instead of when someone remembers to ask. Adds ownerSource ('declared' vs 'caller-identity') to browser_status and browser_list_windows so an agent can tell a self-asserted owner from an authenticated one. The cold-start double-claim race in his Finding 2 is NOT addressed here and the issue stays open for it.

Diagnostic: dump the exact composed badge PNG to disk plus the target (hwnd vs titleContains) before handing it to AD, so the composite can be INSPECTED rather than inferred from a screenshot. Four successive theories about the unpainted first taskbar button were wrong (SVG rasterisation, code-not-running, duplicate sessions, the composite cache); this measurement splits the problem cleanly — if the PNG contains the generic icon then the compositor is exonerated and the fault is delivery to that specific window.

Revert the invented badge placeholder (John: the teal tile was 'hideous', and a full-size Adom logo — 'no it shouldn't'). The badge design is the TAB'S OWN FAVICON with the mini Adom mark inset, full stop. When there is no usable favicon pup now paints NO overlay and logs why, instead of substituting a tile or a blown-up logo. Recorded in the code where it matters: the window that keeps hitting this branch DOES have tabs with real favicons (registration.hanover.com) — it reports 'no favicon anywhere in this window' only because duplicate sessions have split one window's tabs across several session objects, so the session painting that taskbar button can only see the PDF tabs. Fixing identity resolution (HWND instead of the title tag Chrome's PDF viewer cannot carry) removes the cause; inventing placeholder art was papering over it.