REST compressed request body → 500 (should be 415) + raw bytes echoed in error

## Summary

A REST request body with `Content-Encoding: gzip` (or `deflate`/`br`) is handed straight to `JSON.parse` without request-body decompression → 500:

```
SyntaxError: Unexpected token '\x1f' (the gzip magic byte)
```

Two problems:
1. **Wrong status:** HTTP/1.1 §3.5.1 requires **415 Unsupported Media Type** for a `Content-Encoding` the server can't handle, not 500. (The ops API returns 400 for the same input — better, still not 415.) This is a fresh surface of the systemic 4xx-as-500 pattern (see #1299, and F-013/F-019/F-031).
2. **Minor info-leak:** the raw compressed/binary request bytes are echoed in the 500 response `title`, plus per-request `[error]` log noise.

**Severity: Low** — wrong status + small info-leak; no crash or data loss.

## Not-a-bug companions

- A gzip bomb is **safe** here — the bytes fail `JSON.parse` on the magic byte before any decompression, so nothing is inflated (rss_delta 0).
- A plaintext body with a lying `Content-Encoding: gzip` header is accepted (204) and stored correctly — a silent header/body mismatch, but not harmful.

## Suggested fix

Return **415** for an unsupported `Content-Encoding`, and don't echo raw body bytes in the error response. Optionally, support gzip request-body decompression *with* a decompressed-size cap if that's desired.

---
*Found via exploratory QA (scenario QA-206) against `7aaa5a152` on a feature branch; expected to reproduce on `main`. Part of the 4xx-as-500 family (ref #1299). Filed by Claude (Opus 4.8) on Kris's go-ahead.*

Reproduce scenario QA-206 against the REST request-handling entry point on main, using a compressed body and Content-Encoding header. Trace the resulting error response and logging, then verify that unsupported encodings return 415 without exposing raw body bytes or producing the described per-request error noise.

Written by the indexing model from the issue text.