fix(ingest): cap decompression, harden envelope parsing, fix fingerprinting

[ajianaz]

What

Caps gzip/deflate decompression and attachment count/size on ingest, makes envelope item bounds checks overflow-safe, and fixes several fingerprint grouping bugs.

Why

Closes #330
Refs #337 (partially fixed; remaining items under Deferred, so not auto-closed)

A ~1 MB gzip could previously expand without bound and OOM-kill the process.

How

• EnvelopeLimits (defaults: 32 MiB decompressed, 16 attachments, 20 MiB per attachment) plus parse_envelope_with_limits; parse_envelope uses the defaults, so server.rs is untouched.
• Decoders wrapped in Read::take(max + 1); no len * 2 preallocation; Content-Encoding matched case-insensitively (also x-gzip).
• checked_add for item bounds; text items honour declared length when it ends at a newline or EOF, otherwise fall back to newline scan (tolerates miscounting SDKs).
• Fingerprint: last exception in chain, last-frame fallback when no in-app frame, function:/file: tagged components, numbers/hex ids/UUIDs normalised in messages.

Testing

• cargo test --workspace passes
• cargo fmt --all -- --check passes
• cargo clippy --workspace --all-targets -- -D warnings passes
• New tests: gzip/deflate bombs rejected, legit gzip still parses, case-insensitive encoding, u64::MAX length, attachment caps, declared text length, and fingerprint cases.

Deferred (not fixed, #337 remains partly open)

• SDK-provided event.fingerprint (needs a new Event field touching many struct literals).
• Attachments linked only to events[0], transactions/sessions persisted before channel send, empty response body (should be {"id":...}), noisy per-request tracing::info! (all in server.rs).
• Limits are not yet exposed in daemon config.

🤖 Generated with Claude Code