Fix the risk check for a new response cache

An endpoint was slow under load. An AI agent added a 60 second in-memory cache, and p99 latency (the time 99 percent of requests beat) dropped in the load test. Before you merge, you score the load test's numbers to see whether the cache fixed the slow path or only hid it.

An assistant wrote assess_cache_fix(uncached_ms, cached_ms, hit_rate_percent, latency_budget_ms). It is in the editor. It has a bug. Find it and fix it.

Input and output:

• uncached_ms: the latency of a request that misses the cache, in whole milliseconds, 0 or more.
• cached_ms: the latency of a cache hit, in whole milliseconds, 0 or more.
• hit_rate_percent: the share of requests the cache serves, a whole percent from 0 to 100.
• latency_budget_ms: the endpoint's latency budget, in whole milliseconds, 0 or more.
• Return the list of findings, possibly empty.

Rules the tests check:

• Run every check below, in this order, and add each one that applies:
  1. root_path_still_slow when uncached_ms is above latency_budget_ms.
  2. masked_by_cache when uncached_ms is above the budget and cached_ms is at or below it.
  3. blended_over_budget when the blended latency is above the budget. The blend is hit_rate_percent times cached_ms, plus 100 - hit_rate_percent times uncached_ms, all divided by 100. Do not round it.
  4. stampede_exposure when hit_rate_percent is 95 or more and uncached_ms is more than 10 times cached_ms. When cached_ms is 0, any uncached_ms above 0 counts. A stampede is what happens when cached entries expire together and the whole crowd hits the slow path at once.