feat: Q10 (B01/ss07) map support — rooms + rendered map image

[tubededentifrice]

Summary

Adds Q10 (roborock.vacuum.ss07, B01 protocol) map support: requesting current state makes the robot push a protocol-301 map packet, which this PR can parse into a rendered map image, room list, and current-session path data.

This branch is independent of #846 and is based on main.

Protocol Notes

• Q10 does not appear to have a dedicated get-map command. Sending dpRequestDps causes the robot to publish MAP_RESPONSE packets shortly afterward. Firmware also throttles these pushes.
• Full map packets use the 01 01 marker. The parser reads the map id, grid width, compressed layout length, and an LZ4 block containing the occupancy grid plus room records.
• Trace packets use the 02 01 marker. On the tested firmware these contain a 10-byte header followed by big-endian int16 (x, y) point pairs for the current cleaning session path.
• The payloads are unencrypted and do not use the Q7 SCMap protobuf format.

Changes

• Add roborock/map/b01_q10_map_parser.py for Q10 map, room, LZ4, and trace parsing.
• Add request_map() and request_trace() helpers on the Q10 channel.
• Add MapContentTrait for refresh(), parse_map_content(), refresh_trace(), image_content, map_data, rooms, path, robot_position, and raw_api_response.
• Dispatch CLI map-image, rooms, and Q10 position flows through the Q10 map trait.
• Add synthetic/scrubbed fixtures and tests, including maps with no room records yet.

Testing

• uv run pytest — 510 passed on this branch
• uv run pre-commit run --all-files
• Live checked map image, rooms, and trace parsing on Q10 hardware

Credit

The initial 01 01 / 02 01 packet layout reference came from roborock-qseries-map-bridge and the related Home Assistant community thread. The implementation here is separate and is covered by tests against synthetic or scrubbed fixtures.

Follow-ups

• Calibrate trace coordinates to image pixels for floorplan overlays.
• Add dock/charger placement once calibration is available.

[tubededentifrice]

Added Q10 trace parsing for 02 01 MAP_RESPONSE packets and exposed it through MapContentTrait.refresh_trace() plus the q10-position session command.

The tested firmware uses a 10-byte header followed by int16 (x, y) point pairs. The first capture I had was a single-point packet, so the parser handles that case.

Later captures from the same cleaning session showed multi-point packets containing the accumulated current-session path; the follow-up comment below covers that final framing and the added fixture.

[tubededentifrice]

Updated the trace handling with a real 15-point current-session path fixture.

A live corridor run produced 02 01 packets with 1, then 3, then 15 points. Each larger packet contained the earlier points, so the robot is serving the accumulated path for the active cleaning session rather than only the latest position.

The parser now treats the packet body as int16 (x, y) pairs after the 10-byte header. Byte 3 is kept as the session counter, and bytes 8-9 match point-count-minus-one on the captured packet. The path is exposed as structured data through MapContentTrait.path and robot_position; drawing it onto the map is intentionally left to the calibration/layers PR.

[allenporter]

Thank your pushing this forward!

My only high level issue is for Q10 we want to avoid faking a synchronous API where there is not one and keep things entirely asynchronous. WDYT?

[tubededentifrice]

@allenporter yeah I think that's the right call, and will avoid problems with that logic in the first place, let me refactor that a bit

[tubededentifrice]

@allenporter Done, pushed the push-driven refactor. Lines up with how Q10 status already works.
I also rebased the stacked map-layers PR (#848) on top of this so it uses the same push model. Entirely asynchronous now.