feat(connector,session): dispatch multitransport PDUs on IO channel

[Greg Lamberson (glamberson)]

Companion to #1098 — surfaces multitransport request PDUs through the session layer so applications can respond.

What this does

After licensing, the server may send Initiate Multitransport Request PDUs on the IO channel. These use a BasicSecurityHeader rather than the usual ShareControlHeader, so they need special discrimination in decode_io_channel.

This PR:

• ironrdp-connector: Adds a MultitransportRequest variant to IoChannelPdu and discriminates it from ShareControlHeader by checking bytes [2..4] — ShareControl always has pduType | PROTOCOL_VERSION (≥ 0x11) at that offset, while BasicSecurityHeader has flagsHi == 0.
• ironrdp-session: Propagates MultitransportRequest through ProcessorOutput → ActiveStageOutput so applications receive the event.
• ffi: Exposes the multitransport request fields via diplomat bindings (request ID + requested protocol; security cookie deferred until UDP transport is implemented).

Discrimination approach

The key insight is that ShareControlHeader encodes pduType | PROTOCOL_VERSION at bytes [2..4], which is always >= 0x11. A BasicSecurityHeader with TRANSPORT_REQ flag has flagsHi == 0 at that same offset. This lets us cheaply distinguish the two header types without backtracking.

The discriminant logic uses an inner function (try_decode_multitransport) per the project's style guide preference for inner functions over single-use closures.

Relationship to #1098

• feat(connector): implement multitransport bootstrapping handshake #1098 handles the connector-level handshake (collecting 0–2 multitransport requests during MultitransportBootstrapping).
• This PR handles the session-level dispatch (surfacing multitransport requests that arrive on the IO channel during the active stage).

Both are needed for full multitransport support, but they're independent — each modifies different files and can be reviewed/merged in either order.

Builds on: #1091
Related: #1098, #140

[Copilot]

Pull request overview

Surfaces server “Initiate Multitransport Request” PDUs received on the IO channel up through the session layer (and FFI) so applications can react during the active stage, using a fast discrimination path between ShareControlHeader and BasicSecurityHeader.

Changes:

• Update IO-channel decoding to opportunistically decode MultitransportRequestPdu before falling back to ShareControlHeader.
• Propagate and improve visibility of multitransport request events through ProcessorOutput/ActiveStageOutput (incl. structured logging).
• Adjust FFI-facing documentation around deferred exposure of the security cookie.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
crates/ironrdp-connector/src/legacy.rs	Adds/encapsulates multitransport discrimination logic in IO-channel decode path.
crates/ironrdp-session/src/x224/mod.rs	Improves docs and emits structured debug fields when receiving multitransport requests.
crates/ironrdp-session/src/active_stage.rs	Updates ActiveStageOutput docs for multitransport request propagation.
ffi/src/session/mod.rs	Updates diplomat-exposed docs for multitransport request field availability.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Greg Lamberson (glamberson)]

Of course, as 1098 evolves the importance of this PR will change. It looks like it my only be relevant for reconnect scnarios per MS-RDPBCGR 2.2.15.1 .

[Greg Lamberson (glamberson)]

Closing this: the IO channel dispatch logic is fully covered by #1096, which was merged on Feb 13. Rebasing this branch onto current master produces zero diff, confirming everything here is already upstream.

The session-layer multitransport question (whether to surface MultitransportRequest during active sessions for reconnect scenarios per MS-RDPBCGR 2.2.15.1) is tracked as a design question on #1098 instead.