fix(wmo): make high-volume sources fit inside the poll timeout

[seevee]

Follow-up to #74, from a bug found while running it against a live cn-cma-xx entry: after changing the area prefix from 11 to 13, the old alert entity persisted showing "unknown".

Root cause

The entry had not completed a successful poll since the change:

03:21:52 ERROR ... Error fetching cap_alerts_01KZ5CJM0SW673RWPXAJE5VG90 data: wmo: timeout after 30s
03:27:31 ERROR ... Error fetching cap_alerts_01KZ5CJM0SW673RWPXAJE5VG90 data: wmo: timeout after 30s

When the fetch raises, coordinator.data keeps the last successful result but listeners still fire, so _sync_alert_entities saw the stale id still in current_ids and never put it in to_remove. AlertEntity.native_value then returned None for an alert it could no longer resolve — "unknown". The sync logic itself was fine; it was being fed frozen data.

The timeout was not incidental. The shared CAPContentCache held 256 entries; cn-cma-xx needs 501 distinct CAP URLs per poll. One poll evicted its own earliest entries before finishing, so every poll re-fetched all 501 cold — ~32 s against a 30 s default timeout, forever. Being shared domain-wide, it also evicted every other entry's bodies.

1. Bound the cache by bytes, not entries

An entry count cannot bound memory here. Sampled 2026-08-04:

12 CAP bodies from cn-cma-xx: mean 88.9 KiB, max 520.5 KiB

So 256 entries was both ~22 MiB of CMA XML and less than half of one poll's working set. Naively raising it to 2048 would have meant ~178 MiB.

Now a 64 MiB LRU budget measured with sys.getsizeof — real memory, not a character count, since these bodies are largely non-ASCII. That holds CMA's ~44 MiB working set with room for other entries and caps worst-case growth whatever a body weighs. A body larger than the whole budget is not cached at all, since storing it would evict everything then be evicted itself.

2. Skip CAP bodies the geocode filter would discard

The #73 filter is post-fetch, so a narrowed entry still fetched all 501 bodies and discarded 94%. Correct, but useless against the timeout.

Every one of the source's 500 RSS items carries a guid shaped <6-digit area code><serial>_<timestamp> — 52272741600000_20260804103516 is Pingtang County (GB/T 2260 522727), whose CAP body geocode is 522727000000. Where that holds, a prefix decision on the guid equals one on the geocode, so the body need never be fetched.

Measured A/B against the live feed, prefix 13:

	docs fetched	alerts kept	time
with pre-filter	141	71	10.1 s
without pre-filter	478	71	23.7 s

Same 71 alerts either way — the property that matters. This is an optimization under an authoritative filter, never a second opinion about what the user asked for.

Losslessness

It disengages entirely — fetch everything, decide after parsing — whenever the guid cannot answer the question:

• Prefix longer than the embedded area code. Digits 7+ are the serial, where guid and geocode provably diverge: the body's 130709000000 matches a full 12-digit code, the guid's 13070941600000 does not. Filtering there would drop the exact alert requested.
• Non-numeric prefix — says nothing about a numeric guid.
• Any item whose guid does not match the shape — this is not such a feed, and applying the gate to the rest would silently drop the odd one out.
• Zero matches — far more likely a changed convention than a user with no alerts.

Each guard has a test, because the cost of getting one wrong is an alert that never appears. Sources without prefixes set, and every non-CMA source, skip the gate entirely and extract links exactly as before.

Verification

659 tests pass (19 new), ruff/format/mypy clean. Deployed to a dev HA instance: the CMA entry now polls without timing out, where it previously failed every cycle.

One existing test moved from max_entries=2 to an equivalent byte budget.

Assisted-by: Claude:claude-opus-5