feat(server): expose measured bandwidth to the embedder

[Greg Lamberson (glamberson)]

Summary

• After feat(server): measure and report network characteristics #1470/feat(server): measure bandwidth and report it in NetworkCharacteristicsResult #1471, the server can tell the client its measured
  bandwidth over the wire (Network Characteristics Result), but nothing
  exposes that figure outside the crate: snapshot() returns
  RttSnapshot (min/max/avg/sample_count only) and
  autodetect_rtt_handle() carries RTT alone. An embedder's own
  health or flow-control layer that wants the same bandwidth figure
  the client already received has no way to read it.
• Mirrors the existing autodetect_rtt_handle shape exactly: a new
  autodetect_bandwidth Arc<AtomicU32> field (u32::MAX sentinel
  until the first measurement, matching autodetect_rtt), an
  autodetect_bandwidth_handle() accessor, and a
  with_autodetect_bandwidth_handle() builder method for injecting a
  shared instance. Adds AutoDetectManager::bandwidth_kbps() as the
  underlying getter; the field already existed internally with no
  public accessor.
• The store site needed a before/after comparison rather than a plain
  else branch on handle_response's result: that function reports a
  matched RTT sample through its return value but only updates
  bandwidth internally, so a naive else would also fire, and
  mislabel the store as a fresh bandwidth measurement, on any
  unmatched or stray RTT response once a bandwidth figure had been
  recorded at least once. Comparing bandwidth_kbps() before and
  after the call only stores and logs when a measurement genuinely
  completed.
• Adds three tests to the existing autodetect test file, mirroring the
  RTT-handle tests already there: bandwidth_kbps() reflecting a
  completed measurement, the handle's sentinel default, and the
  injected-handle round trip.

Validation

cargo xtask check fmt/lints/tests/typos/locks all pass, including the
3 new tests (22/22 passing in server::autodetect).

Notes

No public API break: RdpServer::new is crate-private, and the public
surface (RdpServerBuilder) only gains an additive optional field and a
new method.

[github-actions]

Additive, well-scoped feature mirroring the existing autodetect_rtt_handle pattern (new builder field, accessor, handle-injection method, plus a getter on AutoDetectManager). One real correctness defect in the server.rs dispatch logic: using a before/after equality check on bandwidth_kbps() to detect a completed measurement misclassifies two legitimate cases as an unmatched auto-detect response — consecutive measurements that compute the same kbps value, and a matched-but-unusable measurement (time_delta_ms == 0) that internally clears bandwidth_kbps to None while leaving the exposed atomic stale indefinitely.

Protocol analysis: accepted — Independently traced handle_response and computed_bandwidth_kbps: time_delta_ms == 0 returns None and the manager clears bandwidth_kbps internally. Confirmed the handoff's 'ambiguous' discrepancy: a matched-but-unusable result is logged as unmatched and the atomic is never cleared, going stale. I also found a more probable trigger for the same root cause: two consecutive successful measurements with an identical kbps value likewise take the 'Unmatched' branch, since before/after value-equality is a weaker test than 'did handle_response consume a matched bandwidth response'. Reported as one finding.

1. non_blocking / low — crates/ironrdp-testsuite-core/tests/server/autodetect.rs
   New tests cover only the sentinel default, handle round-trip, and one successful measurement. Neither scenario that breaks the before/after detection logic (a time_delta_ms == 0 matched-but-unusable result, or two consecutive measurements with an identical kbps figure) is exercised, though both are reachable from client-controlled wire input.