Client can't connect to GNOME Remote Desktop: no Graphics Pipeline (EGFX) advertised — the blocker after #1371

**Summary:** With #1254 and #1371 merged, the connection to GNOME Remote Desktop now gets *past* the Server-Deactivate-All handshake and reaches capabilities exchange — where grd immediately closes it because the IronRDP client advertises **no Graphics Pipeline (MS-RDPEGFX)**. Recent GNOME Remote Desktop dropped its legacy RDP graphics paths and now *requires* EGFX (reproduced here on `gnome-remote-desktop 50`), so this is currently a hard wall for both `ironrdp-web` and the native `ironrdp-client` against grd.

### What grd does

GNOME Remote Desktop's RDP backend rejects any client that doesn't advertise the Graphics Pipeline. Reproduced against `gnome-remote-desktop 50` (system mode / remote-login, Ubuntu), driving it with the real `ironrdp-web` client (bundled in Pangolin) — correct credentials, connection reaches `DEMAND_ACTIVE`, then:

```
[RDP] Client did not advertise support for the Graphics Pipeline, closing connection
[rdp_peer_handle_state_demand_active]: [CONNECTION_STATE_CAPABILITIES_EXCHANGE_DEMAND_ACTIVE] freerdp_peer::Capabilities() callback failed
[RDP] Network or intentional disconnect, stopping session
```

On the client this surfaces as `received disconnect provider ultimatum` (grd's clean MCS disconnect after the rejection). This is not client-credentials or network related. That grd removed the legacy paths and mandates EGFX is stated by GNOME and reproduced by other clients too:
- https://discourse.gnome.org/t/rdp-client-did-not-advertise-support-for-the-graphics-pipeline-closing-connection/27169
- Remmina hit the same: https://gitlab.com/Remmina/Remmina/-/issues/3302

### Why the IronRDP client falls over here

The client stack doesn't wire EGFX into the connection:
- `ironrdp-web/src/session.rs` builds its `connector::Config` with `client_codecs_capabilities` + `ironrdp-graphics` (legacy codecs) and never attaches an EGFX processor.
- `ironrdp-egfx` is currently depended on **only by `ironrdp-server`** — it's at 0× in `ironrdp-connector`, `ironrdp-session`, `ironrdp-client`, and `ironrdp-web`.
- The connector has no way to set `SUPPORT_DYN_VC_GFX_PROTOCOL`, so even with a graphics DVC attached grd/Windows won't open the EGFX channel — that's exactly what #1237 addresses.

So the connection can never satisfy grd's Graphics-Pipeline requirement today.

### Relationship to existing work

- #1016 (closed) — original "cannot connect to gnome remote desktop"; closed as a duplicate on a Server-Redirection lead, which was a misdiagnosis. This EGFX requirement is the actual blocker.
- #1362 / #1253 → fixed by #1254 + #1371 (Deactivate-All). That unblocked the *previous* stage; EGFX is the next one.
- #1237 (open PR) — `SUPPORT_DYN_VC_GFX_PROTOCOL` early-cap flag: the connector-side prerequisite.
- #1175 (ClearCodec) and #1443 (RemoteFX Progressive) — client-side decode paths.
- #1057 / #1099 — `ironrdp-egfx` crate + server integration (merged).

### What seems to be missing to connect to grd

1. Advertise the GFX protocol early-cap flag from the connector (#1237).
2. Wire an EGFX client processor into `ironrdp-web` (a `DvcClientProcessor` for `Microsoft::Windows::RDS::Graphics` → `GraphicsPipelineClient`) and route its `BitmapUpdate` callbacks into the existing canvas rendering.
3. Codec coverage for what grd actually sends.

On (3), a useful data point: in our capture grd accepted an `RDPGFX_CAPVERSION_107` CapsAdvertise from a client that advertised **neither AVC444 nor AVC420** (`H264 (AVC444): false, H264 (AVC420): false`). So an EGFX client without H.264 — using Uncompressed / RemoteFX Progressive (#1443) / ClearCodec (#1175) — appears sufficient for grd; a hardware/OpenH264 decoder does not look mandatory for this server.

### Offer

We have a GNOME Remote Desktop instance (`gnome-remote-desktop 50`, system mode) that reproduces this reliably and can test client-EGFX branches against a real grd server — happy to validate a wiring branch end-to-end.

Start in ironrdp-web/src/session.rs and inspect the connector Config, then review #1237 and the existing ironrdp-egfx server integration. Trace how a DvcClientProcessor and GraphicsPipelineClient would connect BitmapUpdate callbacks to the current canvas rendering. Done means the client advertises the GFX protocol, establishes EGFX with GNOME Remote Desktop 50, and handles the codecs that server sends.

Written by the indexing model from the issue text.