fix: request Q10 maps through dpMultiMap

[tubededentifrice]

Summary

Independent transport slice extracted from #900. Q10 map refreshes now use the protocol's asynchronous dpMultiMap list/get exchange and wait for the matching MAP_RESPONSE packet before publishing an update.

Why

dpRequestDps refreshes ordinary Q10 status values, but it does not reliably cause every Q10 firmware version to publish its map. That left callers waiting for a packet that might never arrive, or falling back to an old cached map even
though the rest of the device state had refreshed.

Map retrieval uses a separate protocol flow:

1. send dpMultiMap with op: list
2. receive the available saved-map IDs asynchronously
3. send dpMultiMap with op: get for the selected ID
4. receive the map as a protocol-301 MAP_RESPONSE

The implementation must therefore remain asynchronous; get acknowledges the request but does not contain the map itself. We also wait for a real map or trace packet rather than any trait update, because status/restriction changes can re-render the cached image and must not be mistaken for a fresh map response. Concurrent requests are coalesced because the firmware throttles map pushes, and an expected command failure is contained so it cannot terminate the persistent subscription loop.

Changes

• replace the generic DPS request with dpMultiMap list → get → MAP_RESPONSE
• coalesce concurrent refreshes and cancel or retry them deterministically
• keep packet correlation and listener state private
• catch only RoborockException at the refresh boundary
• cover delayed, stale, malformed, cancelled, failed, and concurrent responses
  through the observable map subscription API

Validation

• pytest -q — 886 passed, 86 snapshots passed
• pre-commit run --files ... — all hooks passed

Relationship to #900

This PR is independent and targets main. The rendering work is split into #902, #903, and #904; #900 remains the aggregate real-device/Home Assistant before-and-after reference.