feat: add Q10 customized cleaning controls

[hCoureau]

Q10 customized cleaning requires typed settings and device confirmation before starting a selected-room clean. This adds global water/pass/route controls, per-room settings codecs, and a confirmation-driven room-cleaning trait.

Scope and dependencies

This draft contains the cumulative map-control work from #934 and archive work from #937–#939; archive parser support from #936 is merged. Its inherited archive implementation now uses the composed Q10CleanRecordDetail API and shared lifecycle fixes from the archive stack.

After the preceding work lands, the planned partition is:

1. Advanced-cleaning enums and global water/pass/route controls.
2. Per-room writable/reported settings models and wire codec.
3. Confirmation-driven room cleaning and selected-room start, including map invalidation.

Position, zoned cleaning, goto, and the common-coordinate point are already upstream through #908. #965 is merged. Upstream main through b3a98b9 (7.12.0) is integrated.

Behavior

• Writable and reported settings use separate RoborockBase models. Writes accept supported enums; reads preserve unknown integer values. Command snapshots and private reported-state copies protect command targets from caller mutation.
• DP 62/63 use COMMON (101); cleaning mode (137) and selected-room start (201) use direct data points.
• Callers first request a complete room-settings snapshot. A clean publishes settings and waits for a matching compact echo or full response before changing mode and starting.
• Settings-only writes also request a full response because the physical device does not always emit a compact echo after docking.
• Encoders reject invalid/duplicate room IDs, unsupported values, empty selections, and oversized collections. Decoders reject malformed framing and duplicate rooms.
• Device discovery enables advanced controls for the physically verified roborock.vacuum.ss07 model. The direct Q10 factory defaults to enabling them.

Lifecycle and map validity

Room operations snapshot their inputs, capture the current map revision, and validate room IDs after acquiring the existing write lock. An operation queued across map invalidation is rejected even if a refreshed map reuses the same room IDs. Map validity is checked again after confirmation and before publishing the selected-room start.

Local saved-map apply invalidates settings before publishing. The confirmation deadline includes settings publication and the full-response request. Device teardown invalidates settings and cancels the active room command sequence; future cleanup also handles invalidation during a failed or cancelled publish.

These guards cannot retract a command already published before a map change is observed. Reads and setting confirmations have no map-generation identifier, so concurrent changes from another client still require authoritative device updates. Inherited clean-history requests retain their documented late-response ambiguity barrier.

Allen’s follow-up feedback on merged #936 is addressed by separate clean-record and saved-map decoder tests, with no conditional assertions.

Validation

Validation of 6c8075d:

• uv run pytest -q on Python 3.13: 1,655 passed, 53 xfailed, 92 snapshots passed.
• All pre-commit hooks passed, including Ruff, mypy, codespell, and structured-file checks.
• uv build passed for both wheel and sdist.
• Affected protocol suite on Python 3.11 and 3.14: 96 passed, 10 snapshots passed on each version.
• Before this test-only follow-up and upstream merge, the full cumulative suite passed on Python 3.11 and 3.14: 1,655 passed, 53 xfailed, 92 snapshots passed on each version.

No physical-device run was performed for this revision.

Coverage includes sanitized physical fixtures, simulator dispatch, matching confirmations, timeout/cancellation, caller mutation, concurrent writes, queued operations across map invalidation, invalidation after confirmation or during mode publication, early invalidation during map apply, stalled publication, and device teardown.

Earlier Q10 S5+ validation exercised global setting round trips and a customized single-room clean, then restored the original presets and normal cleaning mode. The post-dock full-response fallback was verified on the device. An earlier wheel was exercised in Home Assistant; the hardware scenarios have not been rerun for this revision.

Home Assistant controls and destructive map operations are outside this contribution. No credentials, personal room labels, floorplans, or private raw captures are included. Related: #767.

[hCoureau]

On hold following the review feedback on #933: please do not review the current cumulative diff.

After the read-only and map-control stacks land, this draft will be rebased and repartitioned into focused changes:

1. advanced-cleaning enums and global water/pass/route controls
2. per-room customized-setting models and wire codec
3. the confirmation-driven room-cleaning trait and selected-room start flow

Each part will be submitted sequentially against main, with its own focused tests and reviewer guide.