Resume retained driver services issued during DriverEntry

[stakach]

Problem

A hosted driver can issue a blocking ZwCreateFile or another retained kernel service from DriverEntry. The startup component pump receives the request and parks its Reply, but then blocks in pump_recv waiting for DriverEntry completion. The retained work is redriven only by the later executive event loop, which cannot start until DriverEntry returns. The first native Mup provider fixture exposed this exact deadlock at ZwCreateFile(\Device\Mup).

Acceptance

• Model DriverEntry as a resumable startup continuation with its exact physical lane, Reply, and partial launch ownership retained.
• Redrive admitted kernel-service work while startup is suspended, without replaying DriverEntry or inventing a terminal status.
• Resume the same startup lane after the service Reply is acknowledged; only then read the actual DriverEntry verdict and publish the driver.
• Test nested/reentrant service dispatch, cancellation/stop, and uncertain Reply effects in focused crates before native integration.
• Demonstrate a native driver ZwCreateFile inside DriverEntry reaching a real provider and returning, under a bounded boot; do not use a synthetic success or special-case image/device names.

This is a general NT driver-startup requirement exposed while working on #71 and #79. The current Mup provider integration fixture registers from a genuine PsCreateSystemThread worker to exercise the later live path while this startup behavior is implemented. Strict win32k admission #17 separately prevents the current boot from reaching the executive event loop.

[stakach]

Post-PR78 design audit: the DriverEntry pump already parks the exact service Reply, and component_shared_pump::receive checks nested ready work. However redrive_nested_hosted_file_work requires SERVICE_DELAY_DRAIN_HANDLER, which is null until ExecNtHandler is constructed after boot-driver launch (service_sec_image.rs near 7984). A receive/yield-only change cannot complete CREATE or preserve startup ownership. Implementation sequence: (1) crate-tested DriverStartupContinuation retaining exact lane/dispatch/Reply and partial launch ownership through service park, ACK, resume, stop and uncertain effects; (2) bootstrap-safe canonical File/PM work authority before resuming DriverEntry, then nested redrive under the parked parent; (3) move the native MUP provider ZwCreateFile probe into DriverEntry and prove real provider completion in bounded boot. No native behavior changed by this audit. Working next on #79 live forwarding coverage while #81 remains open.