Pup - the AI's own browser

@@ -1043,3 +1043,36 @@ consumers actually read, with no error anywhere. session as the release. Verify by fetching the tarball at the version you just shipped (a 404 means you published a release, not a package) and by diffing the packaged files against the repo copies — Kyle found the slug bug only because he compared all nine files, not just the docs he came for.++## Ask the AI to report bugs — and scope anything you throttle at the response chokepoint++The Adom team filing wiki issues against this bridge has been the single most productive bug channel+we have. In ~2 days it produced: the CPU-pegging orphan-renderer freeze (#14/#21), the respawn breakage+(#15), the session-tracking purge (#16), the repo-vs-release divergence (#19), and a concurrency ++readiness report that caught a live blocking regression hours after I shipped it (#22). **None of those+were findable on a maintainer's machine** — they came from real installs with different browsers, AD+versions, concurrent agents, a Mac, a stalled download.++So pup ASKS for reports, in the place the AI actually reads (the SDK's first principle: the caller reads+your OUTPUT, never your on-disk skill). `_reportIssues` carries the repo slug, the exact+`adom-wiki issue list` / `issue create` commands, and what evidence to include (verbatim response JSON ++bridge version + OS). It also routes AD-core problems to `adom/adom-desktop` so reports land on the repo+that owns the code. Opt out: `browser_configure {reportIssues:"off"}`.++**Throttling is the whole design.** A line on every response trains the caller to skip the field; a line+on every FAILURE is a bug report waiting to be filed. So: always on a failure (evidence still in hand),+once per bridge process on the first verb (orientation before anything breaks), then every ~40th call.++**THE TRAP, and it is general: a response chokepoint carries MACHINE traffic, not just AI traffic.**+I put the invite in `sendJSON` (all ~155 response sites, one place — correct), then measured that the+first real verb after a restart carried **nothing**. Cause: AD probes `/health` (and `/status` for the+bridge chip) every ~15s, those replies flow through the same `sendJSON`, and the first probe after spawn+silently consumed the once-per-process invitation. The fix is to scope it to real caller traffic+(`res._adomCommand` is set only for actual verb dispatch), so a probe can neither consume the orientation+invite nor advance the periodic counter.++**Generalize:** any budget, counter, once-per-process flag, rate limit, or sampling decision you attach+to a shared response path must ask "who is this response FOR?" first. Health probes, status chips and+supervisors will burn a caller-facing budget long before a caller ever arrives — and it fails silently,+because the feature simply never appears. Verify by triggering the real path (restart, then inspect the+FIRST verb), not by reading the code and assuming.