meta-exporter: CDP plumbing has no timeout — an endpoint that accepts but never answers hangs the exporter forever and writes no failure document #2175

Summary

pm-stack/meta-exporter/meta-quota-export.mjs has no timeout anywhere in its CDP plumbing, so a browser debug endpoint that accepts the connection but never answers hangs the exporter forever instead of producing one of its designed failure documents:

• httpJson (meta-quota-export.mjs, CDP plumbing section) — await fetch(url) with no AbortSignal; used for ${cdpBase}/json/list in both run() and fetchPaygBalance().
• connectWs — the promise resolves only on ws.onopen and rejects only on ws.onerror; if the socket opens but the page never answers, send()'s per-call promise is stored in pending and never settled (no onclose handler rejects pending calls), so evaluate() (which awaits client.send("Runtime.evaluate", …)) hangs indefinitely.
• The in-page fetch calls in fetchQuotaPayloads likewise carry no timeout, though Runtime.evaluate with awaitPromise: true means a hung in-page fetch also never returns.

The module's own header documents the contract this breaks: every failure mode is supposed to write a failure document (cdp-unavailable exit 4, fetch-failed exit 7, …) so a failed tick "can never be mistaken for a reading", and consumers derive laptop-unreachable only from the age of latest.json. A hang produces no document at all — under the shipped systemd units the only backstop is meta-quota-export.service's TimeoutStartSec=120, which SIGTERMs the process: still no failure document, no exit-code semantics, and the stale latest.json is then misread downstream as the laptop being unreachable rather than the browser/CDP being wedged.

Evidence (verified this run on main c58507a3)

• Grep: no timeout / AbortSignal / setTimeout anywhere in meta-quota-export.mjs.
• connectWs: pending promises are resolved/rejected only in ws.onmessage; there is no ws.onclose handler at all, so a socket that closes mid-Runtime.evaluate also leaves evaluate() pending forever.
• Sandbox probe: started a TCP server on 127.0.0.1:19299 that accepts connections and never replies, then ran the shipped exporter against it:
  node meta-quota-export.mjs --cdp-port 19299 --out-dir /tmp/probe-metaexp/out under timeout 8 → exit 124 (killed by timeout; the exporter never returned), and the out-dir contained zero files — no latest.json failure document, no history.jsonl entry.
• Control behaviour by contrast: an unreachable port (connection refused) does produce the designed cdp-unavailable failure document via the catch in run() — it is specifically the accepts-but-never-answers case that has no path to any outcome.

Why it matters

This exporter is the Meta pool's only quota feed (code#1301, epic #1149); the aggregator's pool decisions ingest its file export every 15 minutes. A wedged browser page or CDP endpoint currently turns into up to 120 s of systemd kill-wait per tick, zero diagnostics in the export stream (the failure taxonomy exists precisely to name this state), and a downstream signal that points operators at the laptop's reachability instead of the browser session.

Acceptance criteria

• Every CDP HTTP fetch (/json/list) carries a bounded timeout (e.g. AbortSignal.timeout(...)) that surfaces as the existing cdp-unavailable failure document + exit 4.
• WebSocket send() calls carry a bounded deadline, and ws.onclose/onerror rejects all pending promises, so a hung or closed socket surfaces as fetch-failed (exit 7) instead of hanging.
• The in-page quota fetch is bounded (directly, or transitively via the Runtime.evaluate deadline above).
• A test (the file already has meta-quota-export.test.mjs) covers the accepts-but-never-answers endpoint: the run terminates with a failure document well inside the systemd 120 s budget.
• Healthy-path behaviour unchanged: success document shape, failure taxonomy, and exit codes all as documented in the module header.

Dedup / distinctness

• meta-exporter: window_duration_secs is never validated — a missing/junk duration exports a 'window-NaNs' window as a successful reading #1566 (CLOSED) was window_duration_secs validation in the quota parser — unrelated to CDP transport timeouts.
• feat(quota-plane): Meta adapter Phase 1 — laptop-side quota exporter (subscription-quota API, 15-min file export) #1301 / plan(quota-plane): exception integration — Meta (login, token capture, console API) #1167 / epic(quota-plane): Stage 2 — 15-minute quota gathering in the PM stack, token adapters, automated pool decisions #1149 (OPEN) are the feature/epic for this exporter; none tracks a transport-deadline gap (searched meta-exporter OR meta-quota-export, all states).
• The proxy timeout issues (antigravity-ls-proxy: callRpc has no timeout — a language server that heartbeats but never answers an RPC hangs /v1/models and every chat request forever #2102, codex-proxy: exec transports have no turn deadline — a hung codex exec child hangs the request forever and is never killed #2157, muse-proxy: exec fallback path has no turn deadline — a hung muse exec child hangs the request forever #2159, clef-proxy: data-path upstream fetch has no timeout — a gateway that accepts and never responds holds the /v1/systemone request open (models fetch in the same file pins 10s) #2100) concern other services' upstream calls, not this exporter's CDP channel.