a gzipped response was handed on still labelled gzipped

`fetch` decompresses a response body before anyone sees it, and the headers it
returns still say `content-encoding: gzip`. Copying those onto the decoded bytes
tells the client to gunzip plain JSON: `Decompression error: ZlibError`, which
surfaced as a 502 from the catch that wraps the forward.

It hides well, and that is the part worth writing down. A 401 body is a few bytes
and is not compressed, so every unauthenticated probe passes. The first request
carrying a real credential is the first one big enough to be gzipped, and the
first one to fail - which reads as "the credential broke it".

Measured on alpha in exactly that order: the extension door answered 401 without
a token and 502 with one.

`content-length` goes too. It describes the compressed length and the body being
handed on is not that length.

Response headers are now a different function from request headers, because they
are a different question and treating them as one is what caused this.

sidecar/index.ts

@@ -1,6 +1,6 @@
 import { createSidecarConnector } from '@@/sidecar/connect';
 import { API_URL } from '@@/officer-url.mjs';
-import { getLinkwardenBase, stripHopByHop, redactPath } from './upstream';
+import { getLinkwardenBase, stripHopByHop, stripResponseHeaders, redactPath } from './upstream';
 
 // The officer-linkwarden sidecar: a singleton process that registers with the API server and owns a
 // transparent reverse-proxy to a self-hosted Linkwarden. The platform API is a thin forwarder to this;
@@ -86,7 +86,7 @@ Bun.serve({
 
     return new Response(upstream.body, {
       status: upstream.status,
-      headers: stripHopByHop(upstream.headers),
+      headers: stripResponseHeaders(upstream.headers),
     });
   },
 });