Summary

On a self-hosted setup with an S3 backend that honors Content-Encoding
(Garage, MinIO-style), every bug-report-finalize returns HTTP 500 and the
widget shows "Report processing failed — Debugger ingestion: Failed —
incorrect header check".

The debugger payload is gzip-decompressed twice: once transparently by the
S3 client on read (the object was stored with Content-Encoding: gzip), then
again explicitly by gunzipSync.

Repro

Token / upload-session / screenshot upload all succeed. Only finalize fails:

[Non-fatal] Failed to ingest debugger payload ... incorrect header check
errno: -3, code: "Z_DATA_ERROR"
  at ingestDebuggerPayload  → finalizeBugReportUpload
--> POST /api/embed/bug-report-finalize 500

The stored object is valid gzip (aws s3api ignores Content-Encoding):

head-object → ContentEncoding: gzip, ContentType: application/json
xxd         → 1f8b 0800 ...   (valid gzip magic)
gunzip -t   → OK

Upload sets Content-Encoding: gzip
(storage.ts, ContentEncoding: input.contentEncoding). On read, the HTTP
client transparently decompresses, so readBodyToBuffer returns plain JSON —
then ingestDebuggerPayload runs gunzipSync on it again because
debuggerContentEncoding === "gzip". Doesn't reproduce on plain AWS S3, does on
Garage/MinIO.

Two bugs

1. Double decompression — incompatible with backends that honor
   Content-Encoding. Fix: don't set Content-Encoding on upload (store the
   gzip as opaque bytes), so gunzipSync always sees real gzip.

2. A failed optional debugger payload 500s the whole report.
   finalizeBugReportUpload (upload-session.ts) throws
   INTERNAL_SERVER_ERROR even though the screenshot and report already
   persisted — the log itself says [Non-fatal]. It should degrade gracefully
   (report saved, debugger marked failed) instead.