tests: cover atty-side daemon-verdict path via e2e + reconsider sandbox continue-on-error

[fentas]

Follow-up from #433 / PR (server-side coverage landed there).

#433 had four coverage bullets. The two reliable, self-contained ones landed as atty-guard server tests (atom-overlay Warn classify; loud-skip for the cross-UID gate tests). The remaining two need a different harness:

1. atty-side daemon-verdict integration (REFUSED / banner / trust short-circuit)

The headline gap: security_guard's daemon-Block path (red REFUSED + \x15 readline clear + Critical mark), daemon-Warn arming, and the trust short-circuit over a daemon verdict have no integration coverage — only the response parser is unit-tested.

Attempted + reverted: an in-process fake-UDS-daemon + servicing thread inside the Zig unit test (security_guard_tests.zig). It proved racy and hang-prone — the client connection is sticky, the server thread lifecycle is hard to bound under the build test runner (which also hides child stderr), and runs alternated between pass / assertion-fail / 240 s hang. Not worth merging a flaky threaded unit test.

Recommendation: cover this in the e2e harness (tests/e2e/) instead, driving a real (or scripted) atty-guard so the daemon→atty verdict path is exercised end-to-end without in-process thread races. A scripted-PTY scenario asserting the REFUSED line + cleared readline on a daemon-Block is the right shape.

2. e2e env.toml goldens + sandbox continue-on-error

• e2e env.toml goldens are written but never diffed — either compare them or drop them from the golden set.
• The sandbox eBPF/ONNX workflows run continue-on-error: true; reconsider whether that hides real regressions.

TODO

• e2e scenario(s) for daemon Block → REFUSED+clear, daemon Warn → banner, trust short-circuit over a daemon verdict
• Diff e2e env.toml or remove it from goldens
• Reconsider continue-on-error on the sandbox eBPF/ONNX jobs

[fentas]

Status after investigation — leaving open, headline item deferred; the two minor sub-items reviewed and found to need no change.

1. atty-side daemon-verdict e2e (REFUSED / banner / trust short-circuit) — DEFERRED. Needs a reliable out-of-process daemon driver. The in-process fake-UDS-daemon + servicing thread attempted under #433 was racy/hang-prone (sticky connection, unbounded server-thread lifecycle under the build test runner, alternating pass/fail/240 s hang) and was reverted. The right shape remains a tests/e2e/ scenario driving a real/scripted atty-guard (Block → REFUSED + \x15 clear; Warn → banner; trust short-circuit over a daemon verdict). Same harness gap as #444. Tracking here until the e2e daemon harness lands.

2. e2e env.toml goldens — no change. env.toml and cast.json are written only on --update (src/test/e2e/runner.zig); they are intentional provenance artifacts (atty version + geometry + argv + env that produced the grids), not assertions — the grid.txt / grid.sgr snapshots are the actual golden assertions. Diffing env.toml on a normal run would embed atty.version into the comparison and break e2e on every release bump. Dropping them loses the reviewer-facing provenance record. Leaving as provenance-only is the deliberate tradeoff; documenting that here resolves the ambiguity.

3. Sandbox eBPF/ONNX continue-on-error: true — no change. Correctly configured and documented (.github/workflows/sandbox-{ebpf,onnx}.yml): these jobs need host-specific BPF LSM + privileged-container support that GitHub runners may lack, and scenarios SKIP cleanly when prereqs are missing. The base sandbox.yml is the hard gate; these are best-effort. The annotate-failures step still emits ::error:: annotations on real failures, so regressions remain visible without making the merge gate depend on runner kernel capabilities atty doesn't control. Hard-gating them would produce non-deterministic CI.