conda: large repodata.json fails through the proxy

[pinguinfuss]

Pulling from the big conda channels through the proxy doesn't work. mamba/conda request /conda/conda-forge/linux-64/repodata.json and either get a 502 (with cache_metadata: true) or a truncated body (default config, caching off).

Cause

repodata.json is plain JSON and huge. conda-forge linux-64 is roughly 440 MB uncompressed and a few tens of MB gzipped. Two things bite:

• Since fix(handler): preserve upstream content-encoding for cached metadata #304 the ProxyCached path sends Accept-Encoding: identity so cached metadata bytes stay verbatim. That's the right call for signed indexes (Release, repomd.xml, APKINDEX.tar.gz), but conda's repodata goes through the same path, so every fetch now pulls the full uncompressed file over the upstream hop instead of the gzip'd one Go used to negotiate. With the default http_timeout of 30s the download can get cut off mid-stream; the 200 has already been written by then, so the client just receives a short body and fails to parse it.
• With metadata caching on, the body is read into memory via ReadMetadata, which enforces metadata_max_size (100 MiB by default). 440 MB doesn't fit, so we return ErrMetadataTooLarge → 502. This half actually predates fix(handler): preserve upstream content-encoding for cached metadata #304: the limit always counted the decoded bytes, so linux-64 never fit in the metadata cache. fix(handler): preserve upstream content-encoding for cached metadata #304 just broke the uncached path as well.

As far as I can tell conda is the only ProxyCached ecosystem where this matters. The others serve indexes that are already compressed or tiny, and their upstreams return the same bytes whether you ask for gzip or not.

Proposed Fix

Request gzip explicitly for repodata.json and current_repodata.json instead of identity. Setting Accept-Encoding ourselves already disables Go's transparent decompression, so the compressed bytes plus the Content-Encoding: gzip header get cached and replayed as-is — the same mechanism #304 relies on for identity. Both hops stay compressed, the cache stores the small blob, and metadata_max_size then applies to the compressed size, which fits easily.

conda, mamba and pixi all send Accept-Encoding: gzip for .json URLs and decode the header themselves, so serving it compressed is fine. repodata.json.bz2 is already compressed and should stay on identity.

This needs the ProxyCached path to accept a per-call Accept-Encoding (identity remains the default, so apk/apt/rpm/go/hex are untouched).

Related: #304, #305