Retries stop one attempt short of the configured count

MaxRetries is a deployment-tunable knob (via WEATHER_MAX_RETRIES) that operators use to decide how hard to fight for a successful upstream response before giving up and falling back to stale/error. Right now the client silently gives up one attempt earlier than configured -- with MaxRetries: 2 (documented as "1 initial + 2 retries = 3 total attempts"), it only ever makes 2 attempts. In production this quietly makes the service less resilient to transient upstream hiccups than its own configuration promises, with nothing in the logs or metrics to reveal the discrepancy.

The retry loop's boundary condition is off by one -- it stops one iteration earlier than MaxRetries calls for, so a transient failure that would have succeeded on the final configured retry attempt now exhausts retries and fails instead.

Configure MaxRetries: 2 against a server that fails its first two requests (transient 503) and succeeds on the third. client.FetchCurrent(ctx, "Berlin")

Expected: FetchCurrent eventually succeeds (3 attempts made).

Actual: it returns ErrUpstreamUnavailable after only 2 attempts, never making the third

(successful) one.

A loop boundary (<= vs. <) is one character, compiles either way, and only actually diverges in behavior on the last allowed attempt -- which is exactly the attempt most likely to be exercised in a real "upstream recovers just in time" scenario, and the least likely to be caught by a quick manual check ("it retried, looks fine").

Look at the loop bounds in Client.FetchCurrent (for attempt := 0; attempt <op> c.cfg.MaxRetries; attempt++) and work out, for MaxRetries = 2, exactly which values of attempt the loop body actually runs for versus how many total attempts that represents. Also walk through MaxRetries = 0 by hand -- the same off-by-one has a second, worse consequence there.