fix(codex-bridge): make the failure cap reach and bound the re-arm rate (#906 link 3)

[fujibee]

Part of #906 (link 3). On main.

The measurement first

#906 lists "re-arm loop has no backoff" as a root cause. Measured against the real bridge (a fake WS app-server whose process/spawn exit codes are scripted), that is only half true -- the consecutive-failure cap (--max-failures, default 3) already exists (#209) and fires. Four scenarios, before this PR:

scenario	watch-once returns	before
(a)	every cycle exit 124	cap fires at 3 arms, stopping after 3 consecutive, exit 1
(b)	fail, fail, wake (distinct max_id), repeating	never stops -- the wake reset the failure counter to 0, so a bridge that kept delivering also kept failing, forever
(c)	a wake (distinct max_id) every cycle	2094 arms in 56 s (~37/s), no throttle
(d)	a wake with one repeated max_id	stale-wake guard stops it at 2 arms (correct)

So the incident's "~80 armed from one PID that never gives up" is (b): the cap is real but never reaches, because any wake resets it. And (c) is a latent second hole: the wake -> re-arm path has no rate floor at all. The fork storm the reporter saw (800 PIDs/s) is each armed watch-once forking its own library sourcing under pressure; the re-arm loop does not create that rate, it just restarts it forever -- which is why making the cap reach (b) is the direct fix, and bounding the rate (c) is the belt-and-suspenders.

The change (codex-bridge.js), two ceilings in one place each

(1) A wake decays the failure counter by one instead of resetting it to zero. A wake is progress, not proof the host recovered -- amid failures it is exactly the (b) churn. Forgiving one failure per wake lets a genuinely-recovered bridge (mostly wakes) fall to zero, while a fail/fail/wake churn nets +1 per cycle and reaches the cap. A clean deadline (exit 2 -- a full --timeout that ran end to end) is the stronger signal and still resets outright.

(2) A minimum interval between arms (MIN_ARM_INTERVAL_MS, 1 s), enforced in armWatch -- the one path every re-arm goes through (a clean deadline, a wake and its turn, an idle transition). watch-once's own deadline paces the healthy case at one arm per --timeout (300 s), so the floor is only ever felt by a degenerate loop; a deferred arm still runs, nothing is dropped.

Both are ceilings on "how fast / how forgiving," kept together so the next reader sees (b) and (c) as one subject rather than reading "the cap was fixed" and forgetting (c).

Not done here: widening the stale-wake guard from "one repeated max_id" to "N wakes in a window" -- (d) shows the guard works as specified, and (2) already bounds the distinct-wake flood, so it is a separate judgment, not this PR.

After the fix, re-measured (same harness)

scenario	before	after
(a) every fail	cap fires, 3 arms, exit 1	unchanged -- 3 arms, exit 1 (no regression)
(b) fail,fail,wake	never stops	cap reaches -- stops at ~7 arms, exit 1
(c) wake flood	2094 arms / 56 s (37/s)	~1 arm/s -- 26 arms / 25 s
(d) same-id flood	guard fires, 2 arms	unchanged -- guard fires, exit 1

Verification

• tests/test_codex_bridge.bats +2, driving the real bridge against the scripted fake: (b) the failure cap reaches even when wakes interleave (the bridge stops itself), and (c) a flood of distinct wakes is rate-limited (arm count over ~6 s stays in single digits, where the unbounded loop produced hundreds). The two unchanged scenarios (a)/(d) are already covered by existing tests and the failure-cap test above.
• Full test_codex_bridge.bats 44/44 local.