fix(probe): classify EAGAIN-500 on the gate-health probe's exec round-trip (fabro-71)

[zenprocess]

Closes fabro-sh#122

Closes zenprocess/ao-company#122 ACCEPTANCE item 4 (extend the existing gate-health probe with an exec round-trip so this failure class is caught by monitoring, not by users). Pairs with the ao-company PR stack on ao/fabro-123/snapshot-preflight (PR fabro-sh#145).

Evidence

• ~/.ao/state/fabro-gate-poll.log: ~91:1 ratio of os error 11 (1092) vs the next-largest class (12, snapshot-restore 400).
• The leading HYPOTHESIS (controller source not local) is captured in §2 of the new docs/internal/fabro-122-eagain-hypothesis.md.
• The probe already exercises exec since fec175a65 ops(dellsrv): gate-health probe for per_child_netns=true path (#17); this PR adds the failure-class split monitoring needs.

What this PR does

Adds an EAGAIN-500 classifier to the existing exec round-trip in scripts/ops/dellsrv-forkd-supervision/gate-health-probe.sh:

1. After the exec step scrapes exit_code, the raw response body is checked for the OS-level EAGAIN signature (os error 11 or Resource temporarily unavailable).
2. On match, a structured FORKD-GATE-ALERT reason=exec_eagain_500 is emitted BEFORE the existing exec_nonzero_exit marker.
3. Monitoring can split the failure class from generic exec failures via journalctl -t gate-probe | grep exec_eagain_500.

The change is local + hermetic — no token or argv changes; it reuses the existing in_container_curl, alert, and teardown_sandbox infra. The EXIT trap teardown discipline is preserved (sandbox id scraped before any die()).

Dry-run evidence

$ DRY_RUN=1 bash scripts/ops/dellsrv-forkd-supervision/gate-health-probe.sh
[gate-probe] create: POST /v1/sandboxes tag=zen-gate-base per_child_netns=true
[gate-probe] DRY-RUN: would POST http://127.0.0.1:8891/v1/sandboxes body={"snapshot_tag":"zen-gate-base","per_child_netns":true}
[gate-probe] DRY-RUN: would scrape sandbox id from .[0].id (array-aware), exec /bin/true, then DELETE
[gate-probe] DRY-RUN: skipping all API calls

$ bash -n scripts/ops/dellsrv-forkd-supervision/gate-health-probe.sh && echo OK
OK

In-repo HYPOTHESIS doc (acceptance item 3)

New file docs/internal/fabro-122-eagain-hypothesis.md captures:

• §1: the verbatim observed signature + reproduction-rate table.
• §2: leading HYPOTHESIS — non-blocking fd read returns EAGAIN → fatal; fix = retry-with-deadline bounded by FABRO_EXEC_TIMEOUT. MARKED AS HYPOTHESIS with reasons (controller source not local; alternatives not excluded; no live trace).
• §3: client-side defense in depth (Rust retry already in place; gate-side deferral added by fabro-122; probe-side classification added here).
• §4: explicit non-goals (no controller edits, no live canary, no new production state).
• §5: local-only acceptance evidence; live evidence requires operator on dellsrv.

What I could NOT verify live

• The 5-min launchd-driven poll cycle will not see this branch until it lands in a fabro release that ops installs on dellsrv. The branch is staged for that (the .service/.timer for the probe are part of the parent fabro-71/exec-eagain-control workflow).
• No live trace of the controller read loop.

Branching / merge order

• Branched FROM fabro-71/exec-eagain-control (the WIP branch where the probe scripts live per the brief). Do NOT rebase onto main.
• Pairs with: zenprocess/ao-company PR fabro logs --pretty truncates file paths at 60 chars, no way to configure fabro-sh/fabro#145 on fabro-122-eagain-retryable-classification (the matching gate-side deferral).

🤖 Generated with Claude Code