Windows Python lifecycle under a deny-by-default network policy

[SithiS01]

Hello NeMo Relay maintainers,

We are evaluating NeMo Relay 0.9.x for an offline-first Windows application. Our installed environment uses NeMo Relay 0.9.3 and CPython 3.14.7.

The Python host invokes asynchronous plugin initialization through asyncio.run(). During Windows event-loop construction, the runtime attempts to create its internal wakeup socket pair. In our observed environment this uses an IP socket bind, which the process policy denies before the Relay initializer runs. The Python binding provides asynchronous initialization and activation close, and a separate synchronous subscriber flush.

Could you clarify:

1. Is there a supported Windows/Python configuration that runs the complete enabled plugin-host lifecycle without an IP socket bind during event-loop initialization?
2. Does Relay provide, or plan to provide, a native or blocking Python host interface covering initialization, subscriber flush, bounded cancellation and activation close?
3. Can an upstream Rust or C lifecycle interface preserve Python callbacks, single process-wide activation ownership and equivalent cancellation and cleanup semantics?
4. What integration pattern preserves plugin policy before the first event and reliably cleans up partial initialization, including when close fails?
5. Which exact supported versions, Windows/Python ABIs and dependency constraints apply?

We are seeking a maintainable, version-pinned solution that preserves the process network policy and uses supported runtime interfaces. A documented integration, compatibility fix or upstream enhancement recommendation would be appreciated.

Thank you for your guidance.