Fix decompression bomb vulnerability via expanded size field

[Copilot]

A compressed payload small enough to pass MAX_SIZE wire-size checks could expand arbitrarily during decompression, bypassing size limits during hashing, storage, and quota enforcement.

Changes

Protocol (SPEC.md)

• Added field 12 [expanded size] (uint32 LE, present iff zlib-deflate flag set) to message header; same field added to each attachment header
• Added MAX_EXPANDED_SIZE implementation variable (SHOULD equal MAX_SIZE)
• Reject code 4 now covers both MAX_SIZE and MAX_EXPANDED_SIZE
• Specified that decompressed data MUST exactly match expanded size; mismatch → TERMINATE

Receiver (host.go)

• readHeader: reads h.ExpandedSize from wire when FlagDeflate set; rejects (code 4) if it exceeds MaxExpandedSize
• readAttachmentHeaders: reads att.ExpandedSize for each compressed attachment; accumulates total expanded size (uncompressed items contribute their wire size); rejects (code 4) if total exceeds MaxExpandedSize
• New MaxExpandedSize var loaded from FMSG_MAX_EXPANDED_SIZE env (default: MaxMessageSize)

Hash validation (defs.go)

• hashPayload now counts bytes written during decompression and returns an error if the actual decompressed size doesn't match the declared expandedSize — ensuring tampered or malformed payloads are rejected before storage

Sender (sender.go)

• Captures original size as ExpandedSize before overwriting Size with the compressed byte count, so outgoing headers are spec-compliant

Config

• .env.example: added FMSG_MAX_EXPANDED_SIZE=10240