feat(messages): add OnMapTrace for mower firmware (LZMA-wrapped variant)

[Beennnn]

Summary

Mower firmwares (observed: GOAT A1600 RTK fw 1.15.13) push spontaneous onMapTrace MQTT messages whose body schema is completely different from the existing GetMapTrace response — same NAME, different shape:

{
  "header": {"fwVer": "1.15.13", "tzm": 120, "ts": "...", ...},
  "body": {"data": {
    "mid": "123456789", "batid": "hmfald", "serial": "1",
    "index": "0", "type": "4",
    "info": "<base64 of LZMA1-compressed JSON>",
    "infoSize": 3455
  }}
}

Decompressing the info field yields a small JSON document of the form:

[
  ["5", "0;-11850,-28849;-11800,-28899;...;", "0;-12850,-23699;...;"],
  ["6", "0;-7899,-39700;...;"]
]

— a list of trajectory groups, each holding one or more ;-separated coordinate strings (negative-and-positive ints relative to a map origin). The leading "0" of each segment is an anchor flag, not a coordinate.

The current GetMapTrace._handle_body_data_dict expects traceValue and raises a KeyError, which the legacy fallback in _handle_error_or_analyse catches and logs as WARNING — Could not parse getMapTrace. In one observed setup this produced 217 520 identical warnings in 3 days (~70k/day, ~50/min during mowing).

Change

Add a dedicated OnMapTrace message handler in deebot_client/messages/json/map/__init__.py that:

1. Detects the new format via the presence of info. If absent, returns ANALYSE (defers to the legacy handler so vacuum firmwares are unaffected).
2. Decompresses via the existing deebot_client.rs.util.decompress_base64_data helper — which already accommodates the firmware's trimmed 9-byte LZMA header by injecting 4 zero bytes (see src/util.rs::decompress_lzma).
3. Parses the JSON, drops the leading "0" anchor of each segment, and concatenates the remaining points across groups into the "x,y;x,y;..." shape that downstream consumers (the Map Rust helper in particular) already accept.
4. Notifies MapTraceEvent using the firmware serial as start so the Map helper does not clear the trace on every push (it only clears when start == 0 — which we never produce here).

Registered alongside the other JSON map messages in _MESSAGES, so it is dispatched before the legacy getMapTrace fallback. Vacuums still go through the legacy path with traceValue unchanged.

Compatibility with companion PRs

• fix(messages): skip map-related legacy fallback for mower devices #1565 (skip map-related legacy fallback for mowers) — still useful as a safety net for any other map message that doesn't yet have a proper handler. They don't conflict.
• fix(message): rate-limit "Could not parse" warnings per NAME #1566 (warn-once rate limit) — independent.
• test(hardware): cover xmp9ds (GOAT A1600 RTK) in capabilities event extraction test #1564 (test coverage for xmp9ds) — independent.

This PR alone is sufficient to eliminate the user's specific log storm AND give them a usable trajectory in HA, vs. only suppressing the noise.

Refs

• Disable getMapTrace() for Ecovacs Goat Lawn Mower #1376 — Disable getMapTrace() for Ecovacs Goat Lawn Mower. This PR resolves the underlying issue rather than disabling.
• Ecovacs GOAT A1600 RTK Support #852 — Ecovacs GOAT A1600 RTK Support. Together with the existing xmp9ds.py hardware definition this completes practical map support.

Test plan

• test_OnMapTrace_decompresses_and_flattens_groups — single-group happy path with mock encoded payload
• test_OnMapTrace_concatenates_multiple_groups_and_segments — 2 groups × 2-3 segments → flat point string
• test_OnMapTrace_no_info_field_returns_analyse — defers to legacy handler when info is absent
• test_OnMapTrace_empty_groups_returns_analyse — no event emitted when there are no points
• test_OnMapTrace_corrupt_info_returns_analyse[*] (3 cases: invalid b64, too short, non-JSON) — gracefully degrades, no exception escapes
• test_OnMapTrace_uses_serial_as_event_start — verify MapTraceEvent.start == int(serial)
• Full suite: 705/705 pass, no regression
• Real-world: pending HACS release; the captured payloads in our investigation are reproducible (see Disable getMapTrace() for Ecovacs Goat Lawn Mower #1376 comment for sample)

Notes

• The test file includes a small Ecovacs-format LZMA encoder (_ecovacs_encode) so the round-trip is end-to-end via the real Rust decompressor — no mocking of that path.
• The implementation drops the leading "0" anchor of each segment. We treat it as a "begin-segment" flag (so concatenated trajectories don't accidentally include (0, ?) as a coordinate). If it should instead be preserved as a path-break marker, happy to adjust in review.
• For very long traces, the firmware paginates via index (0, 1, …). This PR currently emits one MapTraceEvent per push without aggregating across index values — start = serial is monotonic per cycle, so the Map helper appends them correctly.

[edenhaus]

We should not encode the data at runtime. Just use the encoded as static string for the test input

[Beennnn]

Pushed MowerMapTrace (accumulator + SVG renderer) on the same branch.

Addresses @edenhaus' review on home-assistant/core#169590 ("the creation of the map should go into the library"): moves the rendering and FIFO-cap accumulation out of the HA integration and into this lib. 9 unit tests added (tests/test_mower_trace.py). The HA Core PR is now a thin consumer.

[edenhaus]

We should use the map capability. MapTraceEvent is also used by the vacuum bots. I also know that mower have a full map, so we should implement that one instead creating a new workaround just for the traces