Android BLE: writes from an unmapped central address wait for a resolution dial (seconds to ~40 s)

[kivtxs]

Seen in the v0.28 device test on two Android phones (Infinix NOTE 12 on Android 13, Seeker on Android 15). This is not a regression; it is the tail latency of Bluetooth-only messaging.

What happens. A peer's writes arrive at our GATT server from its central-role address. When that address is not yet mapped to a peer id, handleReceivedData queues the fragments ("Queued fragment while awaiting device ID") and dials the address to read its identity. The dial goes to a central-role address, which does not advertise, so it can take tens of seconds. Meanwhile the messages sit in pendingInbound, and the sender's core retries.

Measured.

• After Bluetooth was toggled on both phones, the new links reported the neighbour within seconds. Messages then waited about 40 s: 6 messages sent 03:18:33 to 03:18:59 were all delivered 03:19:22 to 03:19:28, when both phones opened fresh connections to each other.
• In a 30-round bidirectional soak with no toggles, p95 reached 11 s for the same reason (11 and 13 "awaiting device ID" queueings on the two phones).

Nothing was lost; every message was delivered by retries.

Ideas.

• Have the central announce its identity on the link it opens. The server would then map the writer's address without dialling back.
• Or let the server resolve the writer through the central link it already holds to the same peer, when exactly one unmapped central appears right after it.

Related: #511 (Bluetooth toggles and density).