Cached weather data never expires

Once any city is fetched successfully a single time, the dashboard serves that exact same reading forever -- the temperature, description, and humidity from that first fetch, no matter how much real time passes or how many times the upstream weather API is called for other cities. Users see a "sunny, 22°C" dashboard during a thunderstorm three days later. Because Status still reports "fresh" (not "stale", which would at least visibly flag the problem), there is no user-visible signal anything is wrong -- this fails completely silently, which is the worst way for a weather app's core feature to break.

Cache.Get computes freshness as "entry's cachedAt minus the current time", compared against the TTL. Since cachedAt is always in the past (or exactly now) relative to the current time, that subtraction is always zero or negative -- and a non-positive duration is always less than any positive TTL, so Fresh is always true, regardless of how long ago the entry was actually cached.

cache.Set("Tokyo", weather) // cached at time T // advance time to T + 11 minutes, with a 10-minute TTL entry, found := cache.Get("Tokyo") // Expected: found == true, entry.Fresh == false (present, but past TTL) // Actual: entry.Fresh == true

a.Sub(b) computes a - b, and subtraction is not commutative -- swapping the receiver and the argument silently produces the negated duration, which still type-checks and still compiles (both are time.Duration), so nothing catches this except actually reasoning about (or testing) what the sign of the result means.

Work out, on paper, what "the cached time minus the current time" represents for a cachedAt that is always in the past relative to "now", versus what "the current time minus the cached time" represents -- then compare against the correct, adjacent use of now() in Cache.Set a few lines above, for which operand plays which role.