PR #662 follow-ups: an exit code with no consumer, two host-coupled tests, a Linux-only hint nf-zhsu ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/664 by tools/beads/import_github.py's reconcile pass.

Suggestions from ninefold-reviewer's review of #662. None of these block it — the fix itself is sound and CONVERGED. They are recorded here so they survive a merge-as-is; if #662 folds them in before merging, close this.

1. EXIT_NO_DISPLAY has no consumer, and three places say it does

probe.py's constant comment:

> probe_all treats every non-zero exit as a FAIL … Its own sweep-level guard keys off this so the sweep can stop rather than produce 34 identical false failures.

probe_all.run_one returns runner(...).ok — a bool. The exit code is discarded, so nothing keys off 3. And sweep()'s guard is an independent godot.display_problem() preflight that runs before any probe launches, which makes a child returning 3 unreachable from the sweep path entirely. tools/tests/test_probes.py's test_a_single_probe_exits_with_its_OWN_code_not_a_plain_failure docstring repeats the same claim ("or the sweep cannot stop early").

The constant is still worth having — a hand-run ./probe.py on a display-less box should exit something other than "a probe failed". Just say that, instead of naming a coupling that is not in the code. Alternatively, have run_one read the code and short-circuit, which would make the comment true.

2. Two new tests depend on Godot being installed on the host

NoDisplayTest.test_a_single_probe_exits_with_its_OWN_code_not_a_plain_failure and test_a_probe_does_not_LAUNCH_GODOT_with_nowhere_to_draw set only NINEFOLD_PROBE_SKIP_BUILD. probe.probe() resolves the engine first (godot_exe() → godot.find()) and returns 1 with "Godot not found" before it reaches the display check. So on a POSIX box with nothing at /opt/godot and no godot on PATH — #584's box state, verbatim — the first test fails (1 != 3) and the second passes for the wrong reason. A stale GODOT_EXE naming a path that cannot exist here (#588's state) does the same via the is_file() arm.

That is the coupling #662's own "Notes for review" says it is removing from this file. The sibling test_a_godot_that_cannot_exec_reports_why already shows the fix: point GODOT_EXE at a real temp file. Moving the display check above the engine lookup in probe.py would also do it.

Latent, not red: both Linux boxes carry /opt/godot today.

3. The wipeout's check-by-hand line is Linux-only, including on the recording box

probe_gate.render_report's wipeout arm prints:

``` xvfb-run -a ./probe.py tools/probes/<name>.json ```

and test_the_report_leads_with_the_HOST_and_offers_no_issue_command pins the string. A wipeout on the Windows box — the platform the baseline actually describes (#566) — hands the operator a command that does not exist there. The pre-existing regression arm a few lines down says Reproduce a single one: ./probe.py tools/probes/<name>.json, unwrapped. Either match it (the causes list above already names the display) or condition on godot.IS_WINDOWS.

4. The two non-display triggers get no preflight, only the after-the-fact wipeout

#632 absorbed #584 (no engine) and #588 (a C:/… path on Linux). #588's stated preferred shape was to make probe.py's "Godot not found" returns an environment refusal and propagate it; #662 leaves them at return 1 and relies on wipeout(), which #588 explicitly said "cannot be a *sole* fix".

The outcome #588 cared about is delivered — no attribution, no paste-ready gh issue create, no baseline write — so this is not a gap in the fix. The residual is cost and specificity: on a Godot-less box the sweep still pays build_once plus 34 launches to reach a conclusion godot_exe() is None could give for free, and the report says "read this as the host" rather than naming the engine. Worth either a cheap symmetric preflight or a line in the PR body recording the choice.

Refs #662, #632, #584, #588.