menu-focus probe is flaky, and a flaky probe makes the UI gate cry wolf nf-4zcc ← Beads

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

Unclaimed and unlabelled — inert backlog, per CLAUDE.md.

Measured

Same tree (9a380fe), no edits between runs:

``` probe_gate (python) -> 28 passed, 0 failed probe_gate (shell) -> 27 passed, 1 failed <- menu-focus

./probe.sh tools/probes/menu-focus.json run 1: PASS run 2: FAIL run 3: FAIL ```

Found while porting probe_gate.sh (#412 item 5 / design 001 piece 5), where the two implementations disagreed on the sweep result and the disagreement turned out to be the *probe*, not the port.

Why this matters more than one red probe

The UI gate's entire premise (#389) is that a NEW failure means "this merge regressed main". That inference is only as good as the probes' determinism. A flaky probe produces:

• false NEW — the gate accuses an innocent merge, and its report offers a paste-ready gh issue create blaming it. Cost is a wrong issue plus the time to disprove it.
• false FIXED — worse. The probe flakes green on the next merge, leaves the failing set, and gets reported as ✓ FIXED. A real regression underneath it would then be *recorded into the baseline as standing* and never shout again.
• baseline churn — every merge rewrites probe-baseline/main.json, so the shared record oscillates.

The second one is the quiet failure and matches the shape #389 exists to end: a gate that reports something reassuring while the thing it guards is broken.

What is not yet known

• Whether the flake is in the probe's timing assumptions (a wait too short for a cold Godot start), in the scene under test, or in the harness.
• Whether other probes flake at a lower rate. A 3-run sample of one probe is not a survey — the honest next step is an N×full-sweep run recording per-probe pass rates, before anyone changes a probe.

Options, uncosted

• Fix the probe (right, if the cause is a timing assumption).
• Have probe_all retry a failing probe once and report FLAKY distinctly from FAIL, so the gate can refuse to record an unstable result rather than absorbing it. Keeps the baseline honest even before the root cause is found.
• Quarantine list, as a stopgap. Cheapest and the easiest to forget about, so it wants an expiry.

The middle option composes best with the gate as built: probe_gate already distinguishes NEW / STANDING / FIXED / GONE, and FLAKY is the missing fourth state that stops a coin-flip being recorded as a fact.