fix(iron-proxy): allow content-encoding header so private git clone works

[pkobielak]

Summary

iron-proxy's strict outbound header_allowlist omitted content-encoding, so the gzip-compressed git-upload-pack POST body was forwarded while the Content-Encoding: gzip header was stripped. GitHub then parsed the gzip bytes as plaintext and returned HTTP 400, breaking private git clone / fetch / pull over HTTPS from sandboxes. gh api and public clones were unaffected.

This adds content-encoding to the header_allowlist in both configs that carry the allowlist:

• services/api/api/iron-proxy.base.yaml (authoritative — baked into the centaur-api image and used to render every per-sandbox proxy config)
• services/iron-proxy/iron-proxy.yaml (standalone egress proxy copy)

Fixes #402

Testing

Verified locally on kind:

1. Added content-encoding to both files, rebuilt centaur-api, redeployed, and forced a rollout.
2. Spawned a fresh sandbox and confirmed:
   • gh api user → 200
   • git clone https://github.com/<org>/<private-repo> → succeeds (exit 0)
3. iron-proxy audit confirmed the git-upload-pack POST now returns 200 (was 400) and Content-Encoding is no longer in stripped_headers.

No test changes required — services/api/tests/test_proxy_config.py asserts transform names only.

Note: because the authoritative file is baked into the centaur-api image, the image must be rebuilt and existing sandboxes/proxies replaced for the fix to take effect.