Silently reconnect BLE after autoreload-induced disconnect

[makermelissa-piclaw]

Fixes #377. Closes #509 as duplicate.

Problem

CircuitPython firmware autoreloads on every BLE-FT mutating
operation — WRITE, WRITE_DATA, DELETE, MKDIR, MOVE —
which tears down the GATT server. See
supervisor/shared/bluetooth/file_transfer.c (search for
autoreload_trigger).

Before this PR, every save / rename / delete / mkdir over BLE
required the user to click Connect again, even though the
bleDevice handle was still valid and the FileTransferClient
state was salvageable. The file dialog also dropped its handle and
operations failed silently if attempted during reconnect.

Fix

1. Silent reconnect path in BLEWorkflow.connect(): when the
   disconnect happens within ~5s of a known mutating op, reconnect
   to the same bleDevice (already paired) without a user
   gesture. Backoff retries at 1500 / 2500 / 4000 ms.

2. _rebindAfterSilentReconnect(): re-fetch BLE-FT service and
   NUS serial characteristics. Crucially, reuse the existing
   FileTransferClient instance instead of calling
   switchToDevice() — the open FileDialog holds bound method
   references that would be orphaned by client replacement. The
   upstream @adafruit/ble-file-transfer-js library lazily re-
   fetches its internal _transfer characteristic via
   checkConnection() on the next op when _transfer is null
   (which onDisconnected already sets), so this works cleanly.

3. Mutating-op wrapper in ble-file-transfer.js: writeFile,
   move, delete, makeDir now:

   • Signal the workflow that a mutating op is in flight
   • await super.<op>() to fire the firmware command
   • await workflow.awaitPostOpReconnect() so the caller sees a
     live GATT connection when the promise resolves

4. awaitPostOpReconnect() polls bleDevice.gatt.connected
   for up to 4s post-op, then awaits _silentReconnectPromise if
   one is in flight. This handles the race between
   super.<op>() resolving and gattserverdisconnected firing.

5. Post-reconnect settle delay (2s): even after GATT is up,
   the firmware VM is still booting (running boot.py, mounting
   CIRCUITPY, initializing BLE service). If the next mutating op
   fires too early, filesystem_lock() returns false and BLE-FT
   returns STATUS_ERROR_READONLY. The settle delay buys time for
   the filesystem mount/lock state to stabilize.

6. Operator-precedence fix in connect(): original code was

   if (result = await super.connect() instanceof Error) { ... }

   instanceof binds tighter than =, so result was always
   a boolean. Parenthesized to:

   if ((result = await super.connect()) instanceof Error) { ... }

Testing

On CLUE (nRF52840) running CircuitPython 10.0.0 over BLE:

• ✅ Rename file → autoreload → silent reconnect → file dialog
  updates with new path → auto-save fires → second autoreload →
  silent reconnect → fully back online
• ✅ Mutating ops on a single editor session no longer require
  manual reconnect
• ✅ No regression on first-time connect or genuine disconnects
  (out-of-range / device powered off) — those still surface the
  normal manual-reconnect UI

Out of scope (not addressed by this PR)

• USB-MSC concurrency: when CIRCUITPY is mounted on a host,
  writes are read-only by design. Already addressed in Cannot Save code.py Edits on Adafruit Qualia ESP32-S3 for TTL RGB-666 Displays #460 / Broaden read-only filesystem messaging to cover non-host-mounted cases (refs #460) #506.
• Firmware-side filesystem_is_writable_by_python() regression
  from CP PR #10659: tracked in BLE File Transfer writes blocked as STATUS_ERROR_READONLY when no USB host attached adafruit/circuitpython#10972. That
  affects the web workflow PUT path, not BLE-FT (which uses
  filesystem_lock(), a different gate).
• Upstream BLE-FT _resolve is not a function: noticed during
  testing that late notifications arriving during reconnect can
  crash processListDirEntry and friends. Pre-existing, not
  regressed by this PR; worth a follow-up upstream PR to guard
  all process* handlers.

[makermelissa]

Thank you