fix: report the frame rate each saver actually achieves

[BernardJen]

The wall is laggy on the split-flap board and slow on some screensavers. Two hypotheses have
now been measured and both refuted, so this ships the measurement rather than a third guess.

What was ruled out

Hypothesis	Verdict
Software-rendering fallback	Refuted. The wall runs ANGLE (NVIDIA, NVIDIA RTX PRO 4000 Blackwell … Direct3D11), gpu_compositing enabled, float targets available, 6000×1200 @1x
The unconditional Art-Net frame readback	Refuted as the cause. Real, but 4%: Mandelbrot at 6000×1200 went 29.8 → 28.5 fps

The readback test is worth a note — against Split Flap it showed no difference, because both
runs sit on the ~120 fps vsync cap and the test simply cannot see through it. That is exactly the
trap #225 flagged ("the ~120 readings are a vsync cap, not a measured ceiling"). Re-running
against a saver below the cap is what produced a usable number.

What remains unexplained is ~6 of 32 cores busy continuously on that machine, with 57 GB RAM
free and a healthy GPU.

The instrument

One property increment per frame, in a loop that already increments a counter. No readback, no
allocation, no timing call on the hot path — the thing being measured must not be changed by
measuring it.

Counters are per runtime and labelled from one level up. The 30 savers each call
createGLRuntime() inside their own create(), so the registry announces the name before
instantiating rather than threading a label through 30 files. The boards are labelled per side,
because in dual view they are separate runtimes and an aggregate would hide one being slower.

Verified in the state the wall is actually in — two boards and a live saver at once:

saver                        mean    min    max   last   n  size
Split Flap (left)            58.2   53.5   62.9   62.9   4  1182x2260
Split Flap (right)           58.2   53.5   62.9   62.9   4  1182x2260
Moire Interference           58.5   53.5   63.9   62.9   4  2582x2260

min/max are per interval, not per frame: a saver that averages 60 and drops to 8 for one
interval is the interesting case, and a mean alone hides it. Every row carries the resolution,
because every fps figure in this repo has been misread at least once for want of knowing what it
was taken at.

On disk

One file, overwritten, never appended — same discipline as the GPU report. Rows are per
saver, not per sample: 32 is the ceiling, main caps the file at 60 lines, and it measured
404 bytes after a minute with three runtimes live. Bounded by the number of savers, not by
uptime.

Counters are read every 15s (memory only) and written every 60s (the only part that touches disk).

Deliberately not included

The Art-Net readback fix, though it is measured and ready. Shipping it alongside would mean the
wall's first numbers are already post-fix, making its real cost on that hardware unmeasurable.
Instrument, then fix, then compare.

Tests

11 new, 618 → 629, on the folding and formatting — a wrong number here sends the next round of
diagnosis somewhere useless. Includes the bound that matters: 50 sample rounds still produce one
row.

The counter itself lives in the GL frame loop and needs a real context, so it is covered by the
end-to-end run above rather than by a unit test.

What to do with it

Once this is on the wall, fps-report.txt sits beside gpu-report.txt in its userData. If the
boards read 12 fps there against 58 here, that is the answer. If they read 58, the lag is not in
the render loop and the next place to look is the capture path — which the ~6 cores already hint
at.