fix(egfx): advertise only capability sets the client can decode

[Anton Isaiev (totoshko88)]

Summary

GraphicsPipelineHandler::capabilities() defaulted to advertising CapabilitySet::V10_7, which
tells the server AVC444 is available unless AVC_DISABLED is set. GraphicsPipelineClient has no
AVC444 decoder — handle_wire_to_surface1 routes Codec1Type::Avc444 and Avc444v2 to
on_unhandled_pdu. The server picks one of the advertised sets and prefers the most capable, so on
a host that supports AVC444 the client asked for a codec it then discarded: every frame of the
desktop was lost, the session looked frozen, and nothing reached on_bitmap_updated at all.

This drops V10.7 from the default. V8.1 keeps AVC420_ENABLED, which does decode, so no H.264
capability is lost, and V8 remains the no-AVC fallback. V10.7 can come back the moment AVC444
decodes — the doc comment and the new test both say so.

Closes #1563. This is item 5 of the #1464 tracking list ("advertise only what we can decode", which
already names AVC444 as the example), addressed for the AVC444 case only.

Why the smaller set is not a downgrade

set	AVC420	AVC444	decodable today
V10.7 (removed)	yes	yes	no — AVC444 has no decoder
V8.1 AVC420_ENABLED	yes	no	yes, via decode_avc420
V8	no	no	yes (Uncompressed, ClearCodec, Planar)

An alternative that keeps V10.x is to advertise it with AVC_DISABLED set, but per
CodecCapabilities::from_capability_set that flag clears avc420 as well, so it gives up H.264
entirely. V8.1 is the better default while AVC444 is missing.

Changes

• crates/ironrdp-egfx/src/client.rs — remove V10_7 from the default capabilities(); document
  why V10.x is absent and what has to happen before it returns.
• Two unit tests: the advertised sets imply no AVC444, and AVC420 stays advertised. They assert
  against CodecCapabilities::from_capability_set rather than naming versions, so they keep holding
  if the set changes shape.
• crates/ironrdp-testsuite-core/tests/egfx/client.rs — client_keeps_avc_caps_with_decoder now
  expects two sets instead of three.

Validation

Reproduced and measured against Windows 11 Pro 25H2 (build 26200.8875), no GPU (WARP software
rendering), same LAN, base tcp rtt 5 ms. Server-side counters sampled with
Get-Counter "\RemoteFX Graphics(*)\*" -SampleInterval 2 -MaxSamples 12 while interacting:

client	session res	output fps avg/max	avg encoding time
default caps, AVC444 selected	3360x1930	0.00 / 0.00	4.50 ms
FreeRDP sdl-freerdp, same host, minutes apart	3360x1930	9.31 / 24.00	5.25 ms

frames skipped/second — insufficient server resources and — insufficient client resources were
both 0.00 and guest CPU stayed at 1–3%: the server was encoding and not throttling. FreeRDP's
near-identical encoding time on the same pipeline confirms the server side was healthy, which is
what places the fault in the client's advertisement.

Local checks, all clean:

• cargo xtask check fmt -v
• cargo xtask check lints -v
• cargo xtask check tests -v — 22 suites, 0 failed
• cargo clippy -p ironrdp-egfx --all-targets --all-features — 0 warnings
• cargo doc -p ironrdp-egfx --no-deps — the two remaining warnings (THIRD_PARTY_NOTICES,
  compositor → private Compositor) predate this branch

cargo xtask check typos -v was skipped: typos-cli is not installed in this environment.

Deliberately not in this PR

• AVC444 itself. It needs YUV plane access that H264Decoder/DecodedFrame do not expose —
  the auxiliary stream is a packed chroma carrier, not an image, so it cannot be reconstructed from
  two RGBA buffers — plus a second decoder context, since each subframe is its own H.264 sequence.
  That is a public-API decision for the maintainers; I sketched a non-breaking shape
  (fn decode_avc444(..) -> DecoderResult<DecodedFrame> defaulting to an error, implemented for
  OpenH264Decoder) in egfx client advertises AVC444 it cannot decode, so frames are dropped #1563 and would rather agree on it before writing the reconstruction.
  I can validate a branch against the 25H2 host above; the counter harness is scripted.
• Diagnosability. egfx client advertises AVC444 it cannot decode, so frames are dropped #1563 also suggests raising the "AVC444 codec not yet implemented" debug! to
  a first-occurrence warn! and adding a typed callback for undecodable content. Both are useful
  and both are separate from this fix, so I left them out rather than mix concerns.
• The no-decoder path. With h264_decoder: None the filter leaves V8 only and a Windows host
  answers with RFX Progressive, which on_wire_to_surface2 drops by default — the same blank screen
  by another route until feat(egfx): wire RemoteFX Progressive decode into WireToSurface2 dispatch #1443 lands. Out of scope here, noted for [tracking] Client-side Graphics Pipeline (EGFX): wire the existing decode core into the connector and client stack #1464 item 4.

[Benoît Cortier (CBenoit)]

LGTM!