ironrdp-egfx: planned timeline for crates.io publish?

First — thanks for the recent EGFX work, the client-side implementation in [#1103](https://github.com/Devolutions/IronRDP/pull/1103) is impressive. Surface management, capability negotiation, frame ack, ZGFX, AVC420 decode through the pluggable `H264Decoder` trait — really well-organised.

The crate currently has `publish = false # TODO: publish` in `crates/ironrdp-egfx/Cargo.toml`. Is there a planned timeline for publishing it to crates.io (presumably as part of an `ironrdp-*` 0.9.x release line)?

**Why I'm asking**: Haven (an Android RDP client built on `ironrdp-blocking` / `-connector` / `-session` 0.8) ships to users targeting modern Windows hosts (Server 2025, Win11) where the legacy bitmap path is line-by-line slow and EGFX/AVC444 is the modern fast path. Adopting the client-side EGFX work would solve that for a large fraction of our users. We could pin to `git` URLs against this repo, but mixing master-pulled `ironrdp-egfx` with crates.io-pinned `ironrdp-svc` etc. trips Cargo's same-source-multiple-versions check (the workspace cross-deps need to be patched together). A published 0.9.x line would let us adopt cleanly.

No pressure on the schedule — just trying to plan whether to wait for a release or invest in a forked-tree integration in the meantime. If there's an open tracker for the next release I should follow instead, happy to redirect.

Reported via context: [GlassHaven/Haven#109](https://github.com/GlassHaven/Haven/issues/109).