feat(server): let RdpServerDisplay report its monitor count

[Greg Lamberson (glamberson)]

Summary

• Stacked on feat(displaycontrol): let a server handler override its capabilities #1917: DisplayControlBackend (ironrdp-server's internal DisplayControlHandler implementor) never overrode capabilities(), so it fell through to the single-monitor default regardless of how many monitors the consumer's RdpServerDisplay actually serves.
• Added a default RdpServerDisplay::monitor_count() method (returns 1, matching today's behavior), fetched once alongside size() before the dynamic channels are attached.
• Threaded the count into DisplayControlBackend so its capabilities() now reports the real value instead of the hardcoded literal.
• A consumer serving more than one monitor can override monitor_count() to report the real total.

Validation

cargo xtask check fmt/lints/tests/typos/locks all pass.

Notes

• Depends on feat(displaycontrol): let a server handler override its capabilities #1917 (DisplayControlHandler::capabilities()); this PR is filed with that PR's branch as its base and will need rebasing onto master once feat(displaycontrol): let a server handler override its capabilities #1917 merges.
• Additive only: one new trait method with a default body, one new field, one call-site change. No existing implementor is affected unless it opts in.

[github-actions]

Potential duplicate detected: #1917.

The ironrdp-displaycontrol hunk reproduces listed PR #1917: a defaulted DisplayControlHandler::capabilities() replacing the hardcoded (1, 3840, 2400) in start(), with the same method name, default values, and near-identical doc wording. This PR is a superset adding the server-side monitor_count plumbing that #1917 lacks, but its core change matches that listed pull request.

Maintainer review is required.

[github-actions]

Additive, low-risk change: RdpServerDisplay::monitor_count() (default 1) is snapshotted before channels attach and threaded through DisplayControlBackend so the DISPLAYCONTROL_CAPS_PDU advertises the real monitor count instead of a hardcoded 1. Default wire behavior is unchanged and the value is conformant under MS-RDPEDISP. Three accepted low-severity findings: the fallback rejects only counts above 1024 (0 is advertised as-is), the new wiring and fallback branch are untested, and monitor_count could be fetched inside attach_channels instead of threaded as a parameter. The displaycontrol capabilities() hunk belongs to stacked base PR #1917.

1. [code-compressor] Fetch monitor_count inside attach_channels instead of threading it as a parameter — low 🟡 — crates/ironrdp-server/src/server.rs
   attach_channels already pulls every other backend input from self (cliprdr, sound, rdpdr factories, display Arc), and its only two call sites (serve_negotiated and run_connection_inner) are async with no other callers. Making it async and reading the count as its first statement removes the new parameter, both duplicated pre-fetch lines, and the thread-through, with identical behavior: the count is still read before any channel is attached or negotiation starts, and the extra await cannot deadlock because the display mutex is not held on these paths.

[github-actions]

This pull request may overlap with #1917.

Both PRs replace DisplayControlServer::start()'s hardcoded (1, 3840, 2400) capabilities with a default DisplayControlHandler::capabilities() trait method that multi-monitor handlers can override, keeping prior behavior by default. #1917's summary matches this diff's displaycontrol changes almost exactly; this PR additionally adds RdpServerDisplay::monitor_count() plumbing in ironrdp-server.

This notice is advisory only. Automated review continues as usual, and how these pull requests relate is for maintainers and authors to decide.

Note

LLM-assisted content (no human feedback).

[github-actions]

Additive, behavior-preserving change: a defaulted RdpServerDisplay::monitor_count() and a defaulted DisplayControlHandler::capabilities() replace the hardcoded single-monitor caps PDU, with the count sampled once per connection and threaded into the private DisplayControlBackend, including warn-and-fallback for 0 and >1024 (verified: the PDU constructor rejects only >1024; 0 passes, so the explicit clamp is needed). Both attach paths (normal and preemption-winner) fetch the count; negotiate_candidate attaches no channels by design; tokio Mutex guards are per-statement temporaries, so no deadlock; all in-repo display implementors rely on defaults and keep identical wire behavior. Published two low-severity maintainability findings (doc semantics ambiguity, duplicated single-monitor constants); rejected two compression candidates that would remove a deliberately added diagnostic or rest on savings the sync capabilities() hook makes impossible.