test(cli): capture process state when the interrupt test hangs

[dennisonbertram]

Refs #1422 — diagnostic, not a fix. Deliberately not Closes.

Why

TestGoCodeScriptStopsHarnessdOnInterrupt fails only in CI, and only as an opaque timeout. It just failed on #1429, a docs-only PR touching CLAUDE.md and the engineering log — so it reproduces against main on a diff containing no code, and every PR is exposed to it.

That failure also corrected the diagnosis. The subtest took 30.11s — the full budget I widened it to in #1423. It is a hang, not a thin margin. Widening the budget bought no headroom; it just made the failure take three times longer to report. Treating a 10s timeout as "slow" rather than "hung" was my error.

Five reproduction attempts, all negative

• macOS, idle: 3/3 pass under -race
• macOS, four CPU hogs running: 8/8 pass under -race
• Linux (Docker, golang:1.26): passes
• Linux under -race with --cpus=2, 3 iterations: passes
• Linux with SIGINT ignored by the parent shell — testing whether the wrapper's bash inherits an ignored disposition, since POSIX inherits that across exec: passes

The Process.Wait defect fixed in #1423 was real and worth removing, but it was not the cause.

What this changes

Nothing about the product, and nothing about what the test asserts. When the wrapper fails to exit, the failure message now includes the process tree with parent, state and wchan, filtered to the wrapper, harnessd, harnesscli and sleep:

wrapper did not exit within 30s of SIGINT
wrapper pid: 1234
relevant processes:
  <pid ppid stat wchan args>

So the next CI failure says what is stuck and in which wait state, instead of only how long it took.

Why not just skip it, or widen the budget again

Skipping would hide a hang that may be a real defect in the wrapper's interrupt path — if the wrapper can hang after SIGINT in some environments, users in those environments get orphaned daemons holding the workspace lock, which is exactly the #1416 symptom this test exists to prevent.

Widening the budget again is what I already did once, on a story the evidence has since disproven. Guessing a sixth time without data would repeat that mistake.

The helper is best-effort and runs only on an already-failing path, so it cannot mask the original failure.

Verification

go test ./cmd/harnesscli -run TestGoCodeScriptStopsHarnessdOnInterrupt passes locally, as it always has — which is the problem. The diagnostic path is exercised only on failure, and its value will be visible the next time CI trips.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WJGxhoFhA8JjkwZFcLGdS5