feat: add Q10 zone, position, and goto support

[hmmbob]

Summary

• expose Q10 robot_position in the common Roborock millimetre coordinate space
• add native zone cleaning with typed points and protocol-layer encoding
• emulate goto with the app's minimum 40 x 40 cm zone
• isolate goto ownership and decisions in a push-driven GotoAction

Why

Q10 firmware has no V1 app_goto_target command. Goto therefore starts a small zone, pauses within 20 cm of the target, and stops after five minutes only if it still owns that cleaning session. It uses streamed map and status updates without extra polling.

The public API uses Q10RoborockPoint; Q10 trace and vector coordinates remain implementation details. The point model matches the one prepared in #934 so that its follow-up work can build on this PR.

Hardware validation

Validated on roborock.vacuum.ss07 firmware 03.11.24. Target (29900, 28650) paused at (30020, 28705), 13.2 cm away, and the robot remained at the destination.

Tests

• 89 focused Q10 tests passed
• all pre-commit hooks passed, including Ruff, mypy and codespell
• 980 additional non-E2E/non-MQTT tests passed locally; one unrelated Windows-only URL-normalization assertion failed

Downstream

• Home Assistant: Add Roborock Q10 position, zone cleaning, and goto support home-assistant/core#177780

[allenporter]

Thank you for this great contribution, see my comments below.

[hmmbob]

@allenporter Thanks for the detailed review. I used Codex to help build this, so I want to be transparent about that. I do understand the functional side of the implementation (it actually developed this based on my questions regarding robot positioning and if we could use the zoned cleaning as alternative for the goto) and have tested it on my own Q10, but I’m happy to have Codex rework the internals along the lines you suggested. It told me already it understood your ideas 😉

Codex:

My understanding is that you’d like the public API to use one common Roborock coordinate space, with typed points and the Q10-specific conversions treated as implementation details. The clean parameters and binary encoding should move to the protocol layer, while the goto lifecycle should be separated into something like a GotoAction, leaving VacuumTrait responsible for listeners and sending the actual commands. Please correct me if I’ve misunderstood any part of that.

Regarding the push updates: on my ss07 running firmware 03.11.24, the map/trace and status updates were streamed reliably during the live goto tests. The robot reached the target and was paused based solely on those updates; we did not use any additional polling or periodic refresh() calls. I was actually quite happy we got this approach to work 😃

There is also a downstream Home Assistant PR using this API: home-assistant/core#177780. You may want to review that as well, particularly to make sure the public API introduced here fits the way Home Assistant consumes it.

If the above matches what you have in mind, I’ll have Codex work through the individual comments and update the PR accordingly. Also, if you prefer to take over and implement it yourself, I'd be ok with that as well. As said, I am not a dev, but a Q10 (ss07) owner happy to have my tokens do some useful work so don't hold back on commenting. I'm actually having quite some fun guiding Codex doing this.

[allenporter]

I'm fine with you continuing. there is a merge conflict.

[hmmbob]

@allenporter This is rebased onto current main and I've worked through and resolved all five review threads. The point API is aligned with #934, and the final safety pass adds explicit confirmed zone ownership before goto may pause. 89 focused tests and all pre-commit hooks pass. GitHub won't let me re-request your review on this fork; the workflow is also waiting for maintainer approval. Ready for another look when you have time.