fix: modules held rather than moved drift one step backwards per move

[socquique]

Problem

SplitFlapModule::start() re-energizes the coil the rotor is resting on before a
move, but it also rewinds stepNumber and leaves it rewound:

void SplitFlapModule::start() {
    stepNumber = (stepNumber + 3) % 4;  // mutates state
    step(false);
}

step() leaves stepNumber pointing at the next pattern, so the rotor sits on
stepNumber - 1. The first start() writes that and nothing moves. The second
writes stepNumber - 2 — a pattern the rotor is not on — and drags the drum one
full step backwards.

moveTo() calls startMotors() on every module on every move, so any module that
is energized and released without stepping loses one step each time. In clock mode
moveTo() runs once a minute, and an hour digit sits still for 59 of those 60
updates:

upstream            after 1h idle: -59 steps (-1.38 flaps on a 48 flap drum)
patched             after 1h idle:  +0 steps

Nothing corrects it, because a module that never turns never passes its hall
sensor. Minute digits pass theirs every ~48 minutes and look fine — which is why
this shows up as "the hours drift and the minutes are OK".

Modules that do step also waste their first commanded step rewriting the pattern
they are already on, so position runs one step ahead of the drum per move.

Changes

• start() writes the holding pattern without touching stepNumber. Coil patterns
  moved to a named table so start() and step() cannot disagree about them.
• moveTo() tracks the steps each module still owes instead of comparing positions
  for equality. A mid-move magnet correction could set position past the target,
  which the equality test then never matched, sending the module round for another
  full revolution.
• moveTo() only energizes modules that actually have to move. Holding all eight
  costs ~200mA each for nothing, and on a shared supply that sag is what makes the
  modules that are moving lose steps.
• homeToChar() passed moveTo() its arguments in the wrong order (true as
  speed), so homing to a character always ran at the minimum speed.
• An i2c error latched hasErrored forever, permanently disabling that module's
  magnet correction after a single transient glitch. It now clears when the module
  answers again.
• Dropped the undefined motorPins[] declaration and the dead file-scope
  hasErrored.

Also here: coil current at power-on

The PCF8575 powers up with every output high, which on this hardware means all four
coils of every module are energized. Nothing wrote them low until
SplitFlapDisplay::init(), which setup() only reaches after mounting LittleFS,
starting the web server and running connectToWifi() — and that blocks for up to
20 seconds. So every boot held the whole display at roughly double its running
current for seconds, longer when the network was down.

setup() now calls releaseAll() first, before STARTUP_DELAY. One i2c write per
module. This is the same root cause diagnosed in #45 against an 11 module display
whose 5V rail collapsed below 3V at power-on.

Testing

Verified on an 8 module ESP32-C3 display, charset 48, 2052 steps/rotation.
Reproduced the drift by cycling 26 words that differ only in the last character at
1s intervals — 60 moveTo() calls per minute, the same count the clock makes in an
hour. Before, the seven idle modules visibly walked backwards; after, they hold.