RateLimit charges fresh HTTP cache hits against GitHub quota

[gemshrine]

Symptom and impact

A fresh response returned by Faraday::HttpCache is counted as a GitHub API request. Repeated cached GETs therefore make Fbe::Middleware::RateLimit#remaining fall even though GitHub receives no requests. For the core resource, Fbe::Octo#off_quota? trusts this local count, so a long-running job can stop for quota exhaustion while the real GitHub quota is still available.

Steps to reproduce

1. Initialize the middleware with a positive cached core remaining count.
2. Make a GET request that is served fresh by Faraday::HttpCache.
3. Read remaining(:core) before and after the cache hit.
4. Repeat cached GETs and check the core quota guard.

Actual result

call invokes track_request before forwarding every non-/rate_limit request, so a fresh cache hit decrements @remaining and increments @counter. When the response completes, sync returns immediately for http_cache_trace containing :fresh; it leaves both decrements in place. Since core off_quota? reads the middleware count without refreshing /rate_limit, cached reads can eventually make it report that the job is off quota.

Expected result

A response served from a fresh local cache should not consume GitHub quota. The middleware should restore the resource count for such a response while retaining any accounting needed for its refresh cadence, or otherwise distinguish cache hits from requests that reached GitHub.

Technical evidence

In lib/fbe/middleware/rate_limit.rb, call always runs track_request(env.url.path) before @app.call. The completion block calls sync, whose first condition returns for a fresh HTTP-cache response. track_request has already decremented @remaining or @searchleft. In lib/fbe/octo.rb, the core off_quota? path reads @limits[:rate_limit].remaining(:core) and does not call rate_limit! when that value is known.

This follows from the middleware flow and cache status handling; no runtime test was run for this report.