feat(graphics): decode RFX Progressive tiles

[Marc-André Moreau (mamoreau-devolutions)]

No description provided.

[Copilot]

Pull request overview

Scopes Progressive RemoteFX decoder state by surface and codec context.

Changes:

• Keys contexts by (surface_id, codec_context_id).
• Adds surface-aware cleanup APIs.
• Adds context isolation tests and shared fixtures.

[github-actions]

Small, self-contained fix to crates/ironrdp-graphics/src/progressive.rs: ProgressiveDecoder's context map is rekeyed from codec_context_id alone to (surface_id, codec_context_id), decode_bitmap/delete_context gain a surface_id parameter, and a new delete_surface method purges all contexts for a surface. All call sites and tests within the file are updated consistently and a new scoping test is added. ProgressiveDecoder has no caller anywhere in the tree (not wired into ironrdp-egfx), so this is an internal correction to not-yet-integrated code; no protocol-facing or public consumer behavior changes result.

Protocol analysis: partially_accepted — Core assessment is correct: MS-RDPEGFX 2.2.2.2/2.2.2.3 field widths (surfaceId u16, codecContextId u32) match the new params, and 3.3.1.1 supports associating codec contexts with a surface, so composite-keying is defensible hardening even though no cited section mandates it. I accept that. I partially reject one framing: the handoff singles out delete_surface's lack of a caller as 'incomplete_evidence,' but the entire ProgressiveDecoder type -- decode_bitmap and delete_context too, not just delete_surface -- has zero callers outside its own tests (verified via repo-wide grep); egfx's DeleteEncodingContext handler only invokes an app callback, never touches ProgressiveDecoder. That's pre-existing state, not a defect specific to the new method.

1. question / low — crates/ironrdp-graphics/src/progressive.rs
   delete_surface has no caller anywhere in the tree yet (ProgressiveDecoder as a whole is not wired into ironrdp-egfx's compositor/client). Given the file's stated purpose is EGFX WireToSurface2 processing, is the wiring (decode_bitmap on WireToSurface2, delete_context on DeleteEncodingContext, delete_surface on DeleteSurface) planned as an immediate follow-up, or is this decoder still in a standalone/staging state pending broader integration?