acceptor: add state-machine fuzz target for AcceptorState

[glamberson]

Background

Sibling issue to #1124's connector_state_machine proposal, scoped to the acceptor side.

crates/ironrdp-acceptor/src/connection.rs defines AcceptorState with 15 states that drive the server-side accept flow. Coverage-guided byte-mutational fuzzing cannot reach the deep AcceptorState variants for the same reason described in #1124: RDP's rigid state machine requires a valid prefix before any deep state is reachable. The bug class (cross-state confusion, security-upgrade race, channel-join replay, reactivation) is structurally invisible to single-PDU oracles on the acceptor side.

Scope

crates/ironrdp-acceptor/ only for this issue. The connector side is tracked in #1124.

Approach

Mirror the replay-then-mutate harness proposed in #1124 for ClientConnector::step, adapted to AcceptorState::step. A hardcoded Vec<Vec<u8>> of valid client-side PDUs replays N-1 frames through the acceptor state machine to reach a target state. libFuzzer then mutates the Nth frame.

Relationship to #1124

Separate harness because the state-set is different (15 acceptor states vs 14 connector states) and the receive orientation is reversed (server-receives-from-client vs client-receives-from-server). Substantial code overlap with the connector harness once both are scaffolded.

Out of scope

• Connector state-machine fuzzing (Add advanced fuzz targets to verify more invariants (round-trip, framing, state-machine…) #1124).
• Full explicit-model state-machine harness (declared transitions, fuzzer-chosen transitions, transition-match assertions) is a much larger effort and a future-direction discussion.
• Acceptor-side oracle work outside state-machine fuzzing.

Provenance

• Add advanced fuzz targets to verify more invariants (round-trip, framing, state-machine…) #1124 (connector_state_machine umbrella; analysis in issuecomment-4556409179)
• Advanced fuzzing with arbitrary #1120 (the broader fuzzing umbrella)