fix(desktop): react to sustained delayed frames

[rldyourmnd]

Problem

Interactive clicks on a WAN desktop could wait behind a media queue even when every frame eventually received an acknowledgement. The native viewer input queue could also close the viewer when a fast burst filled its 128-entry bound.

The Amsterdam trace showed 8 Mbps, hundreds of delayed frame receipts, and input injection itself at 0 ms. A real 30-click tab burst must preserve every button event and ordering.

Change

• Treat two consecutive pacing samples with completed delayed frames as delivery impairment. The existing bounded controller cuts offered bitrate and holds the reduction; isolated spikes remain ignored.
• Expose delayed-frame pressure in health logs.
• Increase the native input queue to 1024 bounded entries.
• Coalesce pointer motion only. Preserve semantic key/button events in order; if full, evict stale pointer motion first and expose coalesced/dropped/max-depth counters.

Validation

• cargo test -p rds-desktop --lib --features x11 — 77 passed
• cargo clippy -p rds-desktop --all-targets --features x11 -- -D warnings — passed
• Full CI lanes are green/passing as they complete.
• Unit regression sends 400 button down/up pairs and verifies all 800 sequence numbers survive.
• Amsterdam release candidate built with rds-agent --features desktop and installed atomically; Herdr/Xorg/user manager were not restarted.
• Fresh native viewer: Full HD presented, input_events_dropped=0, input_pointer_coalesced=0, max queue depth 4. A real 30-click tab burst produced 60 semantic events with no sequence gaps.