bledev on the P4: writes without response are sometimes lost while the P4 is notifying #79

Found while proving bledev.webble (PR stacked on #78): writes without response from a central to the P4 panel (BLE through its C6) are sometimes lost when the P4 is sending notifications at the same moment. Nothing on either side reports it.

What you'd see. The nus gate's ECHO phase stalls. The central sends all 16,384 bytes, and the P4's nus_gate_server.py logs ECHO echoed 15904 of 16384. Everything the P4 sends does arrive.

The evidence, 2026-09-24, MicroPython 1.29 kitchen-sink + speaker-usermod image with micropython-pydevices#10, aioble 0.6.2, bledev from #78 (the webble branch's tests/bledev_web/):

• UP (writes only, no notifications going the other way) never lost a byte in any run.
• On the phone, Android's log shows every write sent with status 0, the 4-byte tail included, so the writes left the phone.
• The S3-to-S3 runs in bledev v1, first half: contract, fake, mpble, auto, nus #78 never lost anything in ECHO.
• With mpftp monitor on the P4's UART for four Windows runs, nothing was printed, but none of those four lost data either.

Not established: where the writes go. Candidates are the ESP-Hosted HCI path to the C6, NimBLE dropping ATT write commands when it's out of buffers while notifying, or the MicroPython IRQ path (invoke_irq_handler prints and swallows an exception from the handler, and mpble copies each captured write inside that handler). The next step is to count _IRQ_GATTS_WRITE events on the board beside the bytes received, which separates "never reached Python" from "reached Python and was dropped".

This breaks bledev's "nothing is dropped quietly" rule on the P4, so a stream over nus needs its own check (or writes with response) there until it's understood.