Bound the BLE connect and file-read waits so they report instead of hanging - #546

Reading device info over BLE could hang forever, leaving the editor spinning
on "Current Device Info" with no way out but a reload. Reproduced on Linux by
letting pairing fail: the connect succeeds, encryption then drops the link,
and the device-info read is issued on a dead connection.

The defect is upstream in `@adafruit/ble-file-transfer-js`. `readFile()` and
`listDir()` install their promise's reject handler *after* writing the
request:

    await this._write(header);
    await this._write(encoded);
    let p = new Promise((resolve, reject) => {
        this._resolve = resolve;
        this._reject = reject;      // too late
    });
    return p;

On a dead link `_transfer` is null, so both writes throw. `_write()` swallows
the error and calls `onDisconnected()`, which has no `_reject` to call yet.
`checkConnection()` likewise catches its own failure and returns normally
rather than rethrowing, so the read proceeds regardless. The returned promise
is then never settled by anyone.

Rather than patch upstream from here, our `FileTransferClient` wrapper guards
the two read paths with `_whileConnected()`: reject immediately if the GATT
link is already down, and reject if it drops while the read is in flight.
Bounding on liveness rather than elapsed time is deliberate -- a large file
read over BLE can legitimately take tens of seconds, so a stopwatch would
produce false failures, while a dropped link is unambiguous. The mutating ops
are left alone, since they are meant to span the autoreload disconnect (circuitpython#377).

That alone stops the hang, because `showBusy()` clears the spinner in a
`finally`. But the rejection then escaped `_getVersionInfo()` and
`_getDeviceInfo()` uncaught, leaving a blank dialog that reads as "the device
answered with nothing". Both now catch and show a message, using the
`#message` element the other modals already use, added to these two.

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

Two follow-ups to bounding the connect, both about how the wait feels rather
than what it does.

`ADVERTISEMENT_WAIT_MS` drops from 5s to 2s. On Linux the event never arrives,
so the wait always runs to the full timeout before the connect is attempted,
and five seconds of it is pure latency. It is not wasted time though: the
discovery session that `watchAdvertisements()` opens is what makes BlueZ
create its device object, without which `gatt.connect()` rejects immediately
as "no longer in range". A second or so is enough for that, and platforms
where the event does arrive get it in about 30ms, so the constant is
irrelevant to them.

The wait was also completely silent, because `clearConnectStatus()` runs just
before it. Two to five seconds of a blank dialog reads as a hang, which is the
impression this whole change set is trying to remove, so show "Looking for
<device>..." until the connect starts.

Untested against hardware: the Linux connect only succeeds about a third of
the time for unrelated host reasons, which makes the latency difference hard
to observe deliberately.

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

The previous commit bounded gatt.connect() in connectToBluetoothDevice() but
missed the copy in _attemptSilentReconnect(), which is arguably the worse of
the two. CircuitPython autoreloads after every mutating file operation, which
drops the link, so that reconnect ladder runs after every save. An unbounded
connect there stalls the ladder, and the mutating op waits on it through
awaitPostOpReconnect(), so a save spins with no way out.

Extracts the timeout-and-cancel race into _connectWithTimeout(device, ms) and
uses it in both places, rather than repeating it.

The silent path gets its own shorter bound. CONNECT_TIMEOUT_MS is 30s, chosen
so a slow-but-real Linux connect is not abandoned; three of those in the
reconnect ladder would be 90s of apparent hang. Ten seconds is long enough for
a reconnect that is going to work -- post-autoreload reconnects land in about
a second -- and past that it has stopped being silent anyway, so failing over
to the manual reconnect UI is the better outcome.

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

connectToBluetoothDevice() showed "Looking for <name>..." for its own device.
Both reconnect paths call it in a loop over every permitted device, so each
call overwrote the last and the message the user was left looking at named
whichever device happened to be last in getDevices() order -- not the one that
would win the race and get connected.

Observed with two boards permitted for the same origin and only one of them
plugged in: the dialog said it was looking for the absent board for the whole
advertisement wait, then connected to the present one and correctly named that
one instead.

Move the message to the callers, which know how many devices are in play, and
say "Looking for N previously connected boards..." when there is more than one.
_connectToGattServer() already names the actual winner once a connect starts.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>