Fade at the iPad app's rate; relay rate report in debug mode

Measured on the booth relay with debug logging on: while dragging a
fader, the DiGiCo iPad app sends /Input_Channels/N/fader at most every
45 ms (about 22 per second; 16/s on average while moving). Fades now
step every 45 ms to match (was 50 ms). Verified on the S31 with a
switched-off matrix send: 23 steps in 1 s, landing exactly on target.

New debug aid: with "Debug logging" on, the module logs every 5 s, per
iPad, the busiest address patterns with their message rate and the
shortest gap between two messages to the same address.

The fade tests now derive their step counts from the exported
FADE_STEP_MS. npm test: 542 checks pass on Node 25 and on Companion's
Node 22.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

companion/HELP.md

@@ -110,7 +110,7 @@ never verified.
 level, matrix send level) has a **Fade time (ms, 0 = instant)**, 0 to 60000 ms. With 0 the level jumps to the target at once, as before; above 0
 the module moves the level there smoothly, starting from where it is now (it reads the level first when it is not known
 yet; if the console does not answer, the target is set at once and a warning is logged). A new level is written 20 times a
-second at most (every 50 ms, steps that would change the level by less than 0.05 dB are left out), and the last write is
+second at most (every 45 ms, about 22 per second, the same rate the DiGiCo iPad app sends a fader drag at; steps that would change the level by less than 0.05 dB are left out), and the last write is
 exactly the target. The **Fade curve** (shown once the time is above 0) is *Fader travel (natural)*, which moves the way a
 fader's travel does (the same taper as the gauges, so the level change sounds even; the default), *Fader travel, ease in/out*
 (the same with a slow start and a slow end), or *Linear in dB* (the same number of dB every step; a fade from or to −∞ runs between −90 dB, where sound