shinytest2 `test-Distribution.R` snapshot is stale, and the diff changes the analytical conclusion (`WideSample`/MaxMin path)

[ms609]

Surfaced by #45 (the MaxMin CI fix). Not caused by it in substance, but revealed by it — and the
revealed difference looks behavioural rather than cosmetic, so it wants a human eye before the
snapshot is simply re-recorded.

What happens

EasyTrees shinytest2 (windows-latest), run
30919105631:
FAIL 1 | WARN 1 | SKIP 0 | PASS 191.

Failure ('test-Distribution.R:9:5'): Distribution and concordance plots render correctly
Snapshot of `file` has changed.
Diff in snapshot file `DistributionDistribution-001-ClusterCons.zip`
< trees <- WideSample(trees[1:125], 48)      # stored snapshot
> trees <- WideSample(trees[77:125], 48)     # this run
...
< # No significant clustering was found.
> # Best clustering was part. around medoids:

Why #45 exposed it rather than caused it

Before #45 this job could not reach its tests: Set up R dependencies failed on the
unresolvable MaxMin Suggests (see #43). With that fixed, setup passes and the suite runs for
the first time in a while.

WideSample() is the one MaxMin-dependent export, and it stop()s when MaxMin is absent
(R/WideSample.R:149-152) — there is no silent fallback. So the stored snapshot was recorded in
an environment whose WideSample() behaved differently from a current, MaxMin-present one.

Why this needs judgement, not just snapshot_accept()

The two halves of the diff are not the same kind of change:

1. trees[1:125] → trees[77:125] — the input range in the app's generated script changed.
2. "No significant clustering was found." → "Best clustering was part. around medoids" — the
   analytical conclusion changed.

(2) plausibly follows from (1), and (1) is the part worth understanding: a different subset being
fed to WideSample() is either a deliberate consequence of MaxMin now being available, or a
symptom. Re-recording the snapshot would make the test green either way, which is exactly why it
should not be the first move.

Note also that R/WideSample.R is in the unowned statistics/support-metrics cluster identified in
#42 — so no red-team area owns this code path today.

Not a merge blocker for #45

The job is continue-on-error: true, deliberately (see shiny-tests-not-in-ci history: the
suite rotted while CI-unwired and was repaired in 6c341bce, then wired as a non-blocking
Windows job). gh pr checks reports it as fail, but it does not gate the workflow conclusion.
Filed separately so #45 stays a CI-plumbing change.

install-pandoc: false on that job — which #45 sets — is not implicated: the only pandoc
mentions in the log are the input echo and package sysreqs metadata, and the download test that
fails produces a zipped R script, not a rendered document. 191 tests pass with it unset.

[ms609]

Root cause found, and the MaxMin hypothesis in the issue body above is wrong — retracting it.

Correcting the original diagnosis

I wrote that "the stored snapshot was recorded in an environment whose WideSample() behaved
differently from a current, MaxMin-present one." Two pieces of evidence kill that:

1. The pre-2026-07-27 version of this snapshot used the old evenly-spaced stride —
   trees[unique(as.integer(seq.int(1, 125, length.out = 48)))], no WideSample() call and
   so no MaxMin involvement at all — and it also said 1, 125. The wrong range predates
   the WideSample logging change entirely (d700bc95 changed only the algorithm on that
   line, carrying the wrong range across).
2. MaxMin is installed on the dev box (0.0.0.9005), so it was not the discriminator
   between local and CI in the first place.

The wrong range has been in the baseline since it was first recorded on 2026-07-03, while
test-Distribution.R:16 has set c(77, 125) since the same day. CI simply never checked it:
the job died in Set up R dependencies (#43) before reaching the suite.

Actual cause

wait_for_idle() does not wait for a pending debounce() timer. mod_data's nTree /
treeRange watchers are debounced (aJiffy = 42 ms, typingJiffy = 105 ms), and while that
timer runs Shiny has nothing to recompute — so it reports idle. set_inputs() +
wait_for_idle() can return before the watcher has even seen the value just set, and a
download captured at that moment encodes the previous state. Whether the timer wins the
race is machine-dependent, which is why the dev box and windows-latest disagreed on this one
snapshot while agreeing on the other ten.

That also vindicates not reaching for snapshot_accept(): it would have re-recorded whichever
side of the race the recording machine landed on, leaving the test free to flip back.

Fix

#48 — wait_stable() now sleeps past the longest debounce window and waits for idle again, and
the baseline is replaced with the windows-latest runner's own output from run 30919105631's
uploaded .new artifact.

Also investigated, and dropped

FetchTreeRange's echo guard identifies a programmatic update's echo by arrival order,
discarding the first firing whose value differs from the pre-push one — which looks like it
could swallow a real edit. Probing the module showed it cannot in practice: arming the guard
is itself a reactive write, so the watcher re-fires and consumes the guard ~42 ms after the
dataset load, long before any user edit could arrive. A candidate fix comparing against the
pushed value would have been actively worse — it would have read that stale firing as an
edit and reverted the push. Two unit tests written to pin the defect both passed against the
unmodified module. No change made, and nothing outstanding here.