Low-priority (P3) follow-ups surfaced during the firmware-update audit and hardware testing that produced #5915 (which fixed the higher-severity issues). Each item below is independent and was implemented as the smallest self-contained change; the hardware-validated OTA/DFU happy paths are unchanged.

🐛 Bug Fixes

• ESP32 BLE OTA handshake fragment-count wait — BleOtaTransport.startOta drove handshake completion off responsesReceived >= packetsSent (the same fragment-count model fix(firmware): harden ESP32 OTA + nRF DFU update paths (hardware-validated) #5915 removed from streamFirmware). Safe at the negotiated MTU 512 but latent at very low MTU. It now completes only on an explicit OK and tolerates interim ERASING, exactly like the fixed streaming loop.
• IPv6 routing heuristic — Esp32OtaUpdateHandler split BLE-vs-WiFi on target.contains(":"), which misclassifies an IPv6 literal as a BLE MAC. Routing now uses a strict 6-octet MAC match (isBleMacAddress); IPv6/hostname targets correctly route to WiFi.
• Manifest md5/bytes not verified — FirmwareRetriever.resolveFromManifest logged but never verified the downloaded .bin against the manifest. It now checks size, then md5 (FirmwareHashUtil.calculateMd5Hex, pure-Okio so it stays in commonMain); a mismatch falls back to the filename heuristics. This surfaces a bad download before the disruptive reboot-into-OTA dance rather than failing device-side mid-flash.
• Empty-firmware slow fail — a 0-byte image skipped the streaming loop and then waited the full 10s VERIFICATION_TIMEOUT before failing. streamFirmware now fails immediately with TransferFailed("Firmware is empty").

🌟 UX

• Serial+ESP32 / TCP+nRF52 dead-end — these transport/device combinations have no update path (getHandler throws), yet the screen still rendered a working "Update" button (method = Unknown) that only failed on press. The ViewModel now maps TCP+non-ESP32 to Unknown, and the Ready screen shows a proactive "firmware updates are not supported over this connection" message instead of an actionable button. New string firmware_update_unsupported_transport.

🧹 Chores / Hardening

• DFU multi-image gap — DfuZipParser transfers only the primary image (app > softdevice_bootloader > bootloader > softdevice). This is correct for app-only Meshtastic OTA zips, but a combined app+SD+BL package would silently flash only one. The limitation is now documented and guarded: the parser logs a WARN when a package declares more than one image. (Multi-image sequencing is intentionally out of scope.)
• Misleading buttonless-DFU warning — SecureDfuTransport.triggerButtonless logged a WARN about a stale bond on the normal success path (the WITH_RESPONSE write times out because the device reboots before the ATT ACK — expected and handled). Downgraded to debug and reworded; the Forget+Re-pair guidance moved to connectToDfuMode's scan-failure error, where it actually indicates a problem.

Testing Performed

Baseline: ./gradlew spotlessApply spotlessCheck detekt :feature:firmware:allTests — green (429 tests).

Added/updated commonTest coverage:

• BleOtaTransportTest — streamFirmware fails immediately on empty firmware (existing startOta OK/ERASING tests already cover the handshake change).
• Esp32OtaRoutingTest (new) — isBleMacAddress accepts MACs and rejects IPv4, IPv6 literals, and hostnames.
• CommonFirmwareRetrieverTest — manifest artifact accepted on matching md5+size; rejected (and falls back) on md5 mismatch and on size mismatch.
• DfuZipParserTest — priority image is chosen when multiple images are present.
• FirmwareUpdateViewModelTest — TCP + nRF52 resolves to Unknown.