probe.sh hardcodes the window, so layout-dependent bugs cannot be probed nf-llll ← Beads

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

Hit this chasing #517 today. Filed unclaimed.

What is missing

probe.sh:68 launches Godot with a fixed invocation:

```bash "$exe" --path . --position -9999,-9999 -- "--probe=$script" ```

There is no way to ask for a window size — not from the CLI, not from the probe JSON. Every probe in tools/probes/ therefore runs at whatever project.godot specifies (1920x1080), and that is the only layout any probe has ever exercised.

Why it matters now

Tonapse's layout is size-dependent by design since #453: Auto resolves to split or one-screen based on the viewport, and #439/#455 added scale boosts on top. So the thing most likely to break is the thing the probe suite structurally cannot reach.

Concretely, on #517 — aedanpope reported a play button that does not toggle and a playhead that does not animate, in split screen, on a 1906x807 window. None of it reproduced at 1920x1080. Bypassing probe.sh and invoking Godot directly:

``` $ godot --path . --position -9999,-9999 --resolution 1906x807 -- --probe=<same script>

1920x1080: focus "▶ play pattern" -> @Button@115 then "⏹ stop" OK, PlayheadShown = lit Loop 1906x807: focus "▶ play pattern" -> @Button@38 (!) then "⏹ stop" OK, PlayheadShown = off Song ```

At his size the label resolved to a different button, and pressing it started Song playback instead of Loop. That is the only lead #517 has, and getting it required going around the runner — which also means it cannot be committed as a regression test.

Two consequences, and the second is the sharper one:

• Layout bugs are unprobeable, so they reach playtests. #517 is the live example.
• Every existing probe's layout coverage is undeclared and accidental. playhead-song.json asserts split-screen behaviour purely because 1920x1080 happens to resolve that way. Change the viewport in project.godot, or move the Auto threshold, and ~32 probes silently re-point at a different layout while still passing. Nothing anywhere says which layout a probe intends.

Worth considering

• A "resolution" key in the probe JSON, passed through as --resolution WxH. Smallest change that closes both halves: layout bugs become reproducible, and a probe that cares can *declare* what it is testing instead of inheriting it.
• A "layout" assertion (expect_prop on whatever the layout mode resolves to) so a probe fails loudly rather than silently re-pointing when a threshold moves. Complements the above; neither replaces it.
• One or two probes pinned at Deck-ish sizes. 1280x800 is the Deck; 1906x807 is what Aedan happened to be running. Right now the suite has no evidence about either, on a project whose stated target is a Steam Deck.
• ~~⚠️ If probes start varying resolution, probe_gate's baseline needs to key on it — a screenshot-comparing gate across two window sizes is otherwise a permanent false NEW.~~ Struck 2026-08-04 — this was wrong, and I wrote it. probe_gate.py compares sets of failing probe NAMES (Sweep.failing: frozenset[str], persisted as {"failing": {name: sha}}, diffed by name in compute_delta). Nothing in this repo compares screenshots, at any resolution — a probe at 1906x807 enters the baseline as a name and passes or fails on its own merits. #514 is unrelated: a frame-counted probe flaking under sweep load.

Correcting it rather than deleting it because the claim was load-bearing in the wrong direction: it was the stated reason #527 shipped with zero probes using the new key, and left standing it would have deterred the Deck-size probes above indefinitely, on a constraint that does not exist. Caught by ninefold-reviewer on #527.

Not blocking anything today; #517 has its lead. But the next layout bug costs the same afternoon.

Related: #517 (the live case), #453 / #439 / #455 (the size-dependent layout), #514 (gate baseline), #410 (probe DSL).