NB - Native Browser Bridge

@@ -11,6 +11,22 @@    the container's `~/.claude/skills` + `~/.codex/skills`. 3. **Discovery** — `discovery_triggers` + `discovery_pitch` on `page.json`. +## bridge.json contracts we declare (and one we deliberately don't)+- **`timeouts`** (AD v1.9.79+): AD hard-caps every bridge verb at 60s unless you declare per-verb HTTP+  budgets. Ours match the bridge's own `timeoutFor()` (`screenshot|record|fetch_url|input_dispatch` →+  120s) plus `wait` (blocks up to its 120s cap): `verbs {wait:125, fetch_url:120, input_dispatch:120}`+  + `prefixes [{screenshot:120},{record:120}]`, `default:60`, and `statusVerb:"nbrowser_status"` (AD+  returns `{stillRunning:true,statusVerb}` on its own timeout → caller polls). Keep the describe+  `timeoutSeconds` in `server.js` aligned with these. Note: the adom-desktop **CLI has its own ~30s+  client timeout**, separate from AD's bridge budget — you can't observe a >30s verb via a bare CLI+  call, but a real relay caller respects the stillRunning+poll pattern.+- **`detect` — intentionally OMITTED.** `detect` is for a HOST APP AD detects/gates. Native-browser+  drives the user's REAL browser via the extension, so the authoritative "is it usable" signal is+  **extension-connected** (`nbrowser_readiness`), not a browser binary on disk — and our read-only+  verbs are always forwarded regardless. A single `hostApp:"Google Chrome"` would MISREPORT the common+  Edge-only machine (verified real: ADOMBASELINE runs fine on Edge with no Chrome), and Edge is+  universal on Windows so "browser installed" is near-zero signal. So we do NOT declare `detect`.+ ## Release the RUNTIME — the exact, proven sequence Deps: none (core `http`/`net`), so the payload is source-only (no `node_modules`).