acceptor: add state-machine fuzz target for AcceptorState

## 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>` 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 (#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

- #1124 (connector_state_machine umbrella; analysis in `issuecomment-4556409179`)
- #1120 (the broader fuzzing umbrella)