server: reactivation drops interleaved virtual-channel PDUs

During server-initiated Deactivation-Reactivation, `RdpServer` gives the multiplexed inbound RDP stream to `Acceptor` while it waits for Confirm Active and Connection Finalization PDUs.

Other traffic may still be queued or in flight. Currently, PDUs unexpected to the current acceptor state can be silently discarded:

- `Framed::read_by_hint()` consumes complete frames that do not match the current hint.
- `CapabilitiesWaitConfirm` attempts to decode every MCS `SendDataRequest` payload as a Share Control PDU and drops decode failures during reactivation.
- `FinalizationSequence` may discard such traffic, advance incorrectly, or fail the connection.

This was observed on qemu-rdp during resize with FreeRDP: before Confirm Active arrived, two frames on the negotiated `drdynvc` channel were classified as unexpected and stalled qemu-rdp.

A state-machine mismatch should be distinguished from malformed wire data. Non-activation traffic should be routed or deferred according to an explicit policy, and only the expected activation PDU should advance the sequence.

Related change: #630 .

Start by tracing RdpServer's server-initiated Deactivation-Reactivation path into Acceptor, then inspect Framed::read_by_hint(), CapabilitiesWaitConfirm, and FinalizationSequence. Reproduce the qemu-rdp resize scenario with FreeRDP and follow queued or in-flight drdynvc traffic. Done means unexpected non-activation traffic is routed or deferred explicitly, malformed data remains distinguishable, and only the expected activation PDU advances the sequence.

Written by the indexing model from the issue text.