A single timeout permanently fails a weather fetch instead of retrying

The entire point of this project's retry/backoff logic is to absorb the kind of brief hiccup a real external API has constantly -- and a plain timeout is the single most common kind of hiccup. Right now, a timeout is treated as a permanent, non-retryable failure: one slow response from the upstream weather API and that city instantly shows an error (or falls back to possibly-stale cache) with zero retry attempts, even though the retry mechanism exists and is fully configured to handle exactly this case for every other kind of transient failure.

IsTransient decides which failures are worth retrying. It currently does not consider ErrUpstreamTimeout transient -- only rate-limiting and generic upstream-unavailable errors are retried. A timeout goes straight to "fail immediately," bypassing the retry loop in Client.FetchCurrent entirely.

Point a Client at a test server that times out on its first request and succeeds on its second, with MaxRetries >= 1. client.FetchCurrent(ctx, "London")

Expected: the client eventually returns the successful result (after one retry).

Actual: FetchCurrent returns ErrUpstreamTimeout immediately after the first failed

attempt, having made no second attempt at all.

IsTransient is a simple || chain over sentinel errors -- dropping one arm of that chain is a one-line change with no compile-time signal, and it silently reclassifies an entire category of real-world failure from "worth retrying" to "give up immediately," directly undermining the resilience story this whole project is built around.

Look at the || chain inside IsTransient and compare it against the doc comment directly above ErrUpstreamTimeout in the same file, which still describes it as something worth retrying.