Name a COMPRESS mismatch instead of reporting an opaque decode failure

[andylemin]

A COMPRESS mismatch between a resolver and a firewall reported only
Failed to decode, the same answer as a corrupt payload or malformed JSON, with
nothing to say which of the three it was or which end was wrong. Compression is
configuration at both ends and is deliberately not signalled on the wire, so
that is the only way a mismatch can ever surface.

The daemon names the direction

The lz4 frame magic settles it in four bytes. Both directions, each proven
against a running daemon:

Daemon	Sender	Logged
COMPRESS: True	plain JSON	payload is not an lz4 frame but COMPRESS is on: the sender is not compressing. COMPRESS must match at both ends
COMPRESS: False	lz4	payload is an lz4 frame but COMPRESS is off: the sender is compressing. COMPRESS must match at both ends

The reply stays Failed to decode, because PROTOCOL.md's reply set is fixed and
a test pins it. A frame whose magic is intact but whose body is damaged is still
reported as corruption, so the new message cannot mislead the other way; that
has its own test.

The resolver names it too

An operator reads the resolver's log first, and the resolver knows what it sent,
which fixes the direction without seeing the firewall at all:

did not confirm the update: b'Failed to decode' (this resolver sent
uncompressed data (COMPRESS: False), so the firewall is set the other way;
they must match)

Every refusal now carries what it usually means — framing skew for Bad length,
release skew for Missing kind, no routable address for No records. A test
asserts each hint corresponds to a reply string PROTOCOL.md documents, so advice
cannot outlive the refusal it explains.

A transport error is no longer called a decode failure

Any read error that was not a timeout was answered Failed to decode, so a
broken connection looked to the sender like a malformed message — and would have
muddied exactly this diagnosis. The protocol has no reply for a transport fault
and the connection has already broken, so it is logged as itself and closed.

Known limit

Over UDP a refused datagram gets no reply, by design, so a mismatch there is
named only in the firewall's log; the resolver sees the circuit breaker open.
Answering an unverified sender would make the daemon a reflector.

Testing

• 126 Rust tests, 238 Python tests, cargo fmt --check and clippy -D warnings clean
• Both mismatch directions and a matching control exercised against a running
  release daemon, with the messages above captured from its log