fix(http): strip zstd from Accept-Encoding so compression sets Content-Encoding (#1092)

compression@1.8.1's negotiator silently fails to set the Content-Encoding
response header when Accept-Encoding carries an unknown token like zstd,
even though the body is still compressed with brotli. Chromium 123+ sends
"Accept-Encoding: zstd, gzip, br" by default, including Playwright's
bundled Chromium over plain HTTP, so any homelab Sencho viewed without a
TLS terminator triggered ERR_CONTENT_DECODING_FAILED in the browser and
rendered as a blank page.

Insert a tiny middleware (step 4 of the canonical pipeline) that drops
zstd tokens from Accept-Encoding before compression's negotiator runs.
The negotiator then picks br or gzip and writes the matching header. The
fix is no-op when zstd is absent. If only zstd was offered, the header
falls back to identity so the response is served uncompressed.

Renumber the canonical-order JSDoc in app.ts from 17 to 18 steps and
update the step-number references in hub-only-guard and proxy-mount-order
test docstrings to match.

11 new tests (8 unit + 3 supertest integration against real compression
with a 3000-byte body) lock in the behavior: zstd-stripping across casing
and q-values, surviving tokens preserved verbatim, identity fallback when
only zstd was offered, Content-Encoding header always written when at
least one supported codec remains.

backend/src/__tests__/proxy-mount-order.test.ts

@@ -2,7 +2,7 @@
  * Regression guard for `createRemoteProxyMiddleware` mount order.
  *
  * `index.ts` mounts every local `/api/<group>` router before the remote proxy
- * at step 13 of the canonical middleware order. A remote-`nodeId` request
+ * at step 15 of the canonical middleware order. A remote-`nodeId` request
  * must short-circuit into the proxy rather than match a local router. If the
  * order were reversed, a GET `/api/stacks` for a remote node would return the
  * control instance's local stack list instead of the remote's.