Art-Net reactive mode has never been tested on the wall, and its readback path just caused a 40x regression

[BernardJen]

What

Art-Net reactive mode (#59) has never been run on the videowall, and the code path it
depends on was just found to be the cause of a 40x frame-rate collapse there. Enabling
it is now the one configuration nobody has tested on the hardware it matters on.

Why this needs testing specifically

The wall measured 1.4 fps on the split-flap board with artnetEnabled: false, because
the frame observer was registered unconditionally and gl-base read the frame before
calling it: 32 synchronous gl.readPixels per frame per runtime, 64 in dual view. On a
discrete GPU each is a pipeline stall plus a PCIe transfer.

The fix does two things, and only the first is proven by turning Art-Net off:

1. the observer is registered only while Art-Net is enabled — so with it off, the
   cost is gone entirely
2. the readback is rate-limited to 1Hz in gl-base — so with it on, the cost should
   be 1/60th of what it was

Nobody has verified (2) on the wall. The reasoning is that 1 readback-set per second
is affordable where 60 were not, but that is arithmetic, not a measurement — and the same
arithmetic on Apple Silicon produced a 4% figure that turned out to understate the real
cost by a factor of 40. Measuring on the development machine is exactly the mistake that
hid this bug in the first place.

What to test, on the wall

• Enable Art-Net and read fps-report.txt. The split-flap board and the screensavers
  should stay near their disabled-Art-Net figures; anything approaching 1.4 fps means
  1Hz is still too fast for that GPU
• Confirm the fixtures actually receive colour — the rate limit moved from the sender
  to the readback, so a bug there would show as Art-Net silently doing nothing rather
  than as an error
• Check the release scene on screensaver exit still fires (artnetReleaseScene),
  since the observer is now unregistered on a settings change and the release path
  runs from hideDvdScreensaver
• Toggle Art-Net on and off while a saver is running, several times. Registration is
  now dynamic; the old code could not get this wrong because it never unregistered

If 1Hz still costs too much

The readback itself is the wrong shape for a discrete GPU. Options, roughly in order of
effort:

• fewer samples — TILES_X * TILES_Y is 32 reads for what becomes a single dominant
  colour; a 4x2 grid would be 8
• one readPixels of a small scaled region instead of 32 scattered tiles
• an async readback via a pixel buffer object, so the CPU never blocks — the correct fix,
  and much the largest

Worth noting the feature is off by default and has no default URL, so nothing here is
urgent. It is a "this is untested on the hardware it was built for" issue, not a bug
report.