bledev v1, part 2: bleak, the BLE REPL, Improv, board_config.ble

[bdbarnett]

The second half of bledev v1 (docs/ble.md §3 in the workspace repo), stacked on #78. Merge #78 first; this PR's base is bledev-core.

What you can do with it

• Talk to a board from a laptop: bledev.bleak.BleakBLE() is the CPython backend (Windows, Linux, macOS; central only), and nus.connect() works from it.
• Get a board's REPL over Bluetooth: put bledev.repl.start(password=...) in main.py, then connect with bledev.repl.connect(ble, password) or any Nordic UART terminal (send an empty line for Password: ). Opt-in only; nothing starts it at boot.
• Set up a board's Wi-Fi over BLE with Improv: improv.serve(ble) on the board, improv.provision(ble, ssid, password) from a laptop or another board. ESPHome/WLED/Home Assistant speak the same protocol.
• board_config.ble is a bledev adapter on all 19 boards with a ble() role, and still answers every bluetooth.BLE method, so raw-API code keeps working. Without bledev installed, the factory returns the raw radio as before.

Gates, all run on 2026-09-24 against the two S3s (LCD-7 serving, T-Embed or the laptop connecting)

• Laptop, over-the-air contract (gatt_central.py through bleak): PASS. Planted peripheral (skips notification 7): FAIL, as it must.
• Laptop, nus 16 KB up/down/echo, byte for byte: PASS, 89-134 KB/s up, 47-49 down, 29-34 echo. Planted bit flips on both sides: FAIL in all three phases.
• REPL from the laptop: right password evaluates 123 * 456 = 56088; wrong password (sent with code that would create /pwned) gets Access denied, a hang-up and no prompt, and /pwned never appears; Ctrl-C interrupts while True. PASS, 3/3 repeats plus the final run. Planted "accept any password": FAIL on five checks, including the code running.
• Improv gate 1, laptop sends a network that doesn't exist: the board reports error 0x03 (unable to connect) and returns to authorized. PASS. Planted "every network joins": FAIL.
• Improv gate 2, a real join: the T-Embed read its own secrets.py on the board and provisioned the LCD-7, which had been taken off Wi-Fi first; the LCD-7 reported provisioned with http://192.168.1.139/, and the laptop pinged it. PASS, twice.
• Board to board after all changes: contract PASS, nus PASS. Fake contract 41/41 on CPython and unix MicroPython; full unittest suite 544 tests OK.

Two mpble bugs the laptop found, both fixed here:

• MicroPython 1.29 on the S3 delivers _IRQ_MTU_EXCHANGED before _IRQ_CENTRAL_CONNECT when the central exchanges the MTU at once (Windows does). aioble drops it, so the board sent 20-byte notifications on a 247 link. Laptop downstream went from 19 to 49 KB/s with the fix.
• Notifications that arrived before subscribe() were queued on a board central, against the contract. The over-the-air check for it fails on the old code.

Wi-Fi and BLE on one S3 (numbers in docs/bledev-internals.md): an idle Wi-Fi association roughly halves nus upstream (77-84 KB/s down to 36-62), and a Wi-Fi stream alongside takes it to 22-39; downstream and echo lose about a fifth. BLE's cost to Wi-Fi throughput could not be measured: the LCD-7 sits at -74 to -82 dBm, where Wi-Fi alone varied from 13 to 155 KB/s between runs.

Not done:

• One REPL gate run in five failed to reconnect (bleak subscribe: disconnected on the second connection 1.5 s after the first closed). The four runs since passed.
• BLE's effect on Wi-Fi throughput needs a board with a stronger Wi-Fi signal.