fix(transport): validate frame lengths and surface unroutable frames

[wboayue]

Closes the first two findings of the tick-by-tick decode-desync investigation
(plans/tick-by-tick-reconnect-decode-desync.md), which was filed against a
live all_last() subscription that began emitting prices with a constant
+1,337,581,200 offset after a usfarm.nj data-farm reconnect and never
recovered — with no decode error anywhere.

The audit found the framing path trusts the wire completely. Two defects, both
absent from the equivalent path in the official C# client.

Trusting the length prefix (fe8910d)

Nothing bounded the 4-byte big-endian length prefix. Four garbage bytes were
read as a body length of up to 4 GiB, which allocated that much and then
blocked in read_exact until that many bytes arrived — consuming and
destroying every real message in between, then yielding one bogus frame with
the stream left mis-framed. The framing is positional, so nothing re-anchors
it.

That is the "never recovered" signature. And because prost skips unrecognized
field numbers, a mis-framed protobuf payload still decodes without error: a
fixed64 read at a shifted offset returns a plausible number. Wrong price,
sane size/time, no failure — exactly what was reported.

parse_raw_message also indexed the first four bytes unguarded, so a body of
0–3 bytes panicked with index out of bounds, killing the dispatcher thread on
the blocking client and the dispatcher task on the async one. Confirmed by test
before the fix.

validate_frame_length now gates both frame readers. The 16 MiB cap matches
Constants.MaxMsgSize, which EReader.readSingleMessage enforces with
BAD_LENGTH. Both directions raise the new Error::InvalidFrame.

Error::InvalidFrame is classified as is_connection_lost, so both
dispatchers take their reconnect branch rather than shutting the client down.
The socket is open but only a fresh connection can re-anchor the framing. This
widened that predicate's documented meaning from "the socket is gone" to "the
stream is unusable in place"; its doc is updated to match.

Dropping unclaimed frames (8bb60dc)

A frame no channel claimed vanished. The blocking transport logged every such
frame at info without distinguishing cases; the async transport's
route_to_shared_channel had no else arm at all. So an unrecognized message
id — the desync fingerprint, since a slipped read makes every subsequent id
garbage — looked identical to an idle connection. That is why the incident
surfaced data-farm notices and no decode error.

report_unroutable_frame splits them: an unknown IncomingMessages kind warns
and publishes UNKNOWN_MESSAGE_TYPE_CODE (-5) to Client::notice_stream
so consumers can react programmatically; a known kind with no current
subscriber stays at info, since that is ordinary steady state and raising the
same signal for it would make the signal worthless.

-5 joins the existing client-side sentinels (-3, -4); TWS uses 0 and up.
Notice::is_handshake_synthetic is deliberately untouched — this is not a
handshake notice.

Together: the desync either cannot happen, or announces itself and reconnects.

Tests

Regression coverage at all three seams — validate_frame_length boundaries,
read_message over an oversized prefix (this one would have allocated 4 GiB
before the fix), and parse_raw_message on 0–3 byte bodies. Unroutable-frame
reporting is tested at the classifier and end-to-end on both transports:
push a frame with an unknown id through MemoryStream, drive the dispatcher,
assert the notice lands on the notice stream.

Gate	Result
cargo test	1351 + 209
cargo test --no-default-features --features sync	1374 + 216
cargo test --all-features	1713 + 321
clippy ×3 configs	clean
rustdoc ×3 configs	clean
integration crates (sync + async)	build
examples ×2 configs	build
just rules-check	33 nodes resolve

Not fixed here

The root cause is not confirmed. The oversized-length path is the most
plausible explanation for the 2026-07-07 corruption, but no capture exists — and
the audit found that MessageRecorder could not have produced one: it runs on
the already-parsed message, so the length prefix is never recorded and unknown
ids collapse to NotValid = -1. Capturing a real desync needs tcpdump or a
tee inside the socket read.

The falsification condition is recorded in the plan: corruption recurring
without an accompanying InvalidFrame or UNKNOWN_MESSAGE_TYPE_CODE notice
would rule this out and put the prost-mis-decode hypothesis back in play.

Also left open, and tracked in the plan: the raw numeric message id is not
threaded into the notice (it has already collapsed to NotValid by the time
routing runs — naming it needs a ResponseMessage shape change), and the 3×
ramp in the original report remains unexplained.