fix(transport): name the offending message id in diagnostics and recordings

[wboayue]

Follow-up to #756, which added the UNKNOWN_MESSAGE_TYPE_CODE notice but could
not say which id it meant.

The information loss

IncomingMessages::from is lossy — every unrecognized value collapses to the
single NotValid variant — and ResponseMessage::from_protobuf kept only that.
So the id was destroyed at construction, before routing ever saw the frame. By
the time report_unroutable_frame matched NotValid, both of its outputs were
id-less: the notice carried a fixed string literal, and the warn! printed an
empty field list, because a protobuf frame has no fields[0] to fall back on.

During exactly the incident this machinery was built for, an operator would get
N byte-identical notices.

The fix

ResponseMessage now carries message_id alongside kind: the numeric value
kind was resolved from, with the PROTOBUF_MSG_ID offset already removed so
it is the value that was actually looked up. ResponseMessage is pub(crate),
so this is not a public API change. Both constructors funnel through a private
new() that computes kind from it, so the invariant
kind == IncomingMessages::from(message_id) has one home rather than being
asserted by hand in two struct literals.

That is what makes the notice diagnostic rather than decorative: scattered ids
mean the framing slipped; one repeated id means IBKR added a message type.

Two more places the same loss survived

Found by the cleanup pass, both beyond the original scope but the same defect:

• The wire recorder fabricated the id. recorder.rs reconstructed the
  frame's id with message_type() as i32. That agrees with the arriving id for
  every recognized message — IncomingMessages::from maps a value to the
  variant with that discriminant — but an unrecognized id resolves to
  NotValid, discriminant -1. So IBAPI_RECORDING_DIR wrote -1 into
  precisely the capture worth replaying: an operator recording a desync burst
  lost the one field identifying the fault. Now reads message_id().
• The handshake reporter had the same gap one phase earlier. The catch-all
  in connection/common.rs logs the kind only, which renders the bare
  NotValid for any unrecognized id — in exactly the reconnect window
  plans/tick-by-tick-reconnect-decode-desync.md is about. It names the id
  alongside the kind now.

Considered and rejected

Recorded so they are not re-litigated:

• Folding kind into a computed message_type() would undo a deliberate
  cache with 51 non-test call sites.
• NotValid(i32) is impossible: IncomingMessages is a pub fieldless
  enum used as a HashMap key in both dispatchers, with as i32 casts and
  const arrays. A payload-carrying variant would silently split
  shared-channel lookup, besides being a public breaking change.

Tests

The id surviving both framings — protobuf, which has no fields[0]
fallback, and text, which needs an id at or below PROTOBUF_MSG_ID to reach
that branch at all — plus a recorder regression test, plus id assertions on the
three existing unroutable-frame tests. The thrice-repeated fixture moved to
helpers::unknown_message_frame / UNKNOWN_MESSAGE_ID, so assertions derive
the id instead of spelling it.

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

Still open on this arc

The root cause of the original 2026-07-07 corruption remains unconfirmed —
see plans/tick-by-tick-reconnect-decode-desync.md. This makes a recurrence
substantially easier to diagnose but confirms nothing on its own. Remaining
there: the raw-frame tap (F7) and five structural follow-ups.