fix(weather): throttle failed forecast fetches, not only successes

[prorochestvo]

WeatherForecastAgent's daily gate keys on the stored MAX(captured_at), which is written
only on success. A location that could not be fetched therefore stayed due for the rest of
the UTC day and was retried on every tick, each retry being another
openMeteoMaxAttempts requests.

Against the outage pattern already measured for this provider — 105 of 177 fetches meeting a
503 over five days, episodes running about three hours per location — the plan's "one
weighted call per location per day" became up to 24 ticks × 5 attempts = 120 calls per
location per day on the hourly cron. A persistent read fault on
ObtainLatestForecastCapture did the same thing from the other side, converting a storage
problem into upstream traffic.

What changed

A per-location marker under repository.ServiceMetaKeyForecastAttemptPrefix in
service_meta counts the day's failed attempts and stamps the last one. The wait doubles
after each failure, so tries land at roughly 0, 1, 3, 7 and 15 hours and then stop.

The spacing is the point, not just the cap: a flat budget burned in the first few ticks would
sit out the rest of the day and miss a three-hour outage recovering. weatherForecastRetryBase
moves the density, weatherForecastMaxDailyAttempts moves the count, and nothing else reads
either.

Every uncertainty resolves to "fetch." A marker that cannot be read, cannot be parsed, or
belongs to another day means a fresh budget — a wrong yes costs one request, a wrong no is a
location that silently stops updating. A failure to write the marker is logged and
swallowed for the same reason: the worst case is that this location keeps the old behaviour
until the write lands.

A deferred location is counted and logged as deferred=, never skipped=. "Already have
today's" and "failing and waiting out a backoff" are opposite states, and spelling both
skipped is what let the unthrottled version read as healthy.

Tests

Through Run: a failed fetch and a failed retain each leave a parseable marker; a spent
budget defers instead of refetching (verified to fail with the gate removed); a marker from
another day is a fresh budget; an unreadable or garbage marker never blocks a fetch; a
location with today's forecast stored writes no marker at all.

Directly on retryWindowOpen, which takes now explicitly and so needs no clock seam: seven
timing cases across the doubling schedule. Plus the marker round-trip, four malformed
encodings, and the wait schedule itself.

go vet, scripts/lint-checks.sh and golangci-lint clean; 41 packages green.

Refs #132