fix(message): rate-limit "Could not parse" warnings per NAME

[Beennnn]

Summary

When a firmware version pushes messages whose on-wire format the lib does not yet support, every push triggers a Could not parse <NAME> WARNING via _handle_error_or_analyse. In one observed case a mower's spontaneous getMapTrace pushes produced 217 520 identical entries in 3 days (~70k/day, ~50/min during mowing), bloating the parent process' log file and any downstream sink (HA recorder DB, Loki, etc.).

The first few warnings are useful — they let an operator notice that something is wrong. Beyond that, identical repeats add no information and only make the rest of the log harder to read.

Change

Per-NAME counter with a default threshold of 3:

• First 3 parse failures for a given message NAME → WARNING (as before)
• 3rd warning is followed by a single notice: "Further 'Could not parse ' entries will be logged at DEBUG level"
• 4th and beyond → DEBUG

Counters are isolated per NAME, so a new message class hitting a parse error still surfaces normally even if another NAME has been silenced.

The 3 existing emission sites all route through the new _log_parse_failure helper:

• _handle_error_or_analyse exception branch (line 68)
• _handle_error_or_analyse ERROR-state branch (line 84)
• MessageBodyData.__handle_body_data exception branch (line 259)

Behaviour for non-throttled flows (SUCCESS, ANALYSE) is unchanged.

Refs

• Related to Disable getMapTrace() for Ecovacs Goat Lawn Mower #1376
• Companion to fix(messages): skip map-related legacy fallback for mower devices #1565 (the getMapTrace mower-skip — together they should fully eliminate the user's observed log storm)

Test plan

• test_warn_once_throttles_repeated_parse_failures — calls Message.handle() THRESHOLD + 2 times on a class whose _handle always raises, asserts THRESHOLD + 1 WARNINGs (incl. the "switching to DEBUG" notice) followed by 2 DEBUGs
• test_warn_once_isolated_per_message_name — burns through the threshold for one NAME, verifies a sibling NAME still WARNs on its first parse failure
• Full suite: 699/699 tests pass, no regression

Notes for review

• The threshold (3) is module-level; happy to make it configurable via env var or Message class attribute if that fits the project style better.
• Counter is module-level state; not reset across the lifetime of a process. A "Restart the parent process to reset" note is included in the threshold-reached message. If you'd rather have an admin API to reset, happy to add it.

[edenhaus]

Please make sure CI is passing

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.99%. Comparing base (8980d8c) to head (b5d93ce).
⚠️ Report is 14 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #1566      +/-   ##
==========================================
+ Coverage   94.92%   94.99%   +0.07%     
==========================================
  Files         156      158       +2     
  Lines        6105     6197      +92     
  Branches      350      352       +2     
==========================================
+ Hits         5795     5887      +92     
  Misses        248      248              
  Partials       62       62              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[edenhaus]

Thanks @Beennnn 👍

Did some small refactoring in the tests

[codspeed-hq]

Merging this PR will not alter performance

✅ 113 untouched benchmarks

---

_{Comparing Beennnn:fix/warn-once-on-message-parse-failure (b5d93ce) with dev (7266b58)}