### What needs to get done Ensure that upstream HTTP requests for mutable repository index and metadata files include cache-revalidation headers (e.g. Cache-Control: max-age=0, must-revalidate or no-cache). Specifically: 1. Identify mutable metadata endpoints (such as apt `InRelease`, `Release`, `Release.gpg`) 2. Inject upstream `Cache-Control: max-age=0, must-revalidate` to try to force revalidation of the cache. 3. Ensure conditional headers (If-Modified-Since, If-None-Match) continue to be forwarded appropriately so upstream mirrors can respond with 304 Not Modified when the cache is actually fresh. ### Why it needs to get done Example failure: https://github.com/canonical/fetch-service/actions/runs/35915975553/job/107367412660 1. The test requested InRelease from security.ubuntu.com. The Squid proxy served an expired cached object (X-Cache: HIT, Expires: 19:02:36 GMT, Last-Modified: 18:32:36 GMT) 2. The test subsequently requested Packages.gz. The upstream proxy experienced a cache miss and fetched the newly-published version from origin (Last-Modified: 19:08:51 GMT). 3. Because the cached InRelease predated the newly updated Packages.gz, the correct checksum for Packages.gz was not listed in InRelease. 4. validatePackagesFile in release.go correctly rejected the file ("Packages file not listed in Release file"),` causing the download to fail with HTTP 403. By having fetch-service enforce `Cache-Control: max-age=0, must-revalidate` on upstream metadata requests, intermediate proxies and caches are forced to conditionally revalidate index files against the upstream mirror, preventing stale metadata from causing spurious integrity verification failures on rolling/active repositories.