Feature: decode zstd (Content-Encoding: zstd) response bodies

[korya]

Problem

A body arriving as Content-Encoding: zstd is not decoded, so the three body assertions refuse rather than run:

$ http-assert --assert-body '"status":"success"' https://api.example.com/
- body: response is zstd-encoded and was not decoded: no decoder for "zstd"; gzip and deflate are supported

--assert-ok, --assert-status and --assert-header* are unaffected.

Why it matters

zstd is a registered content coding (RFC 8878) and is being switched on by CDNs and by services that control both ends. It is rarer than brotli today and getting less rare.

Why it is not supported today

There is no zstd decoder in the Go standard library, and the tool has three dependencies in total — viper was deleted in #54 specifically to cut the count. Adding one is a deliberate trade.

Proposed

Same shape as #77, and worth deciding together with it rather than separately:

• Take the dependency — github.com/klauspost/compress/zstd is the pure-Go option, though klauspost/compress is considerably larger than a brotli-only package.
• Build tag, keeping the default binary dependency-free.

The wiring exists: decoders in main.go maps a content coding to a function, and decodeBody reports an unknown one by name. Supporting zstd is one map entry plus the decoder.

Related

• Feature: decode brotli (Content-Encoding: br) response bodies #77 — the same question for brotli; the dependency decision should be made once for both
• -H 'Accept-Encoding: gzip' silently breaks all body assertions #27 — the decoding stage this would plug into