[rush-daemon][WS2][9/9] Wire host request lifecycle

[mojaza]

Summary

Depends on #8.

Completes the final WS2 host integration layer for microsoft#5897. This stack follows merged microsoft#5949.

Details

• Adds validated request start/envelope, cancellation, typed rejection, and exact-once result controls to protocol 0.5.
• Injects a request resolver boundary that maps validated wire envelopes to the existing phased or global request contracts without copying Rush CLI parsing internals.
• Makes RushDaemonHost own one warm-workspace dispatcher so all control connections share the request scheduler and phased-build coordinator.
• Extends DaemonControlSession with request identity/state validation, tagged stdin, raw-mode acknowledgement, ordered output/events/results, cancellation/disconnect cleanup, bounded backpressure shutdown, and deterministic resource disposal.
• Adds real DaemonFrameListener end-to-end coverage for global/phased execution, warm no-op requests, shared builds across clients, admission/cancellation, interactive I/O, malformed state, graph recreation, and shutdown.
• Fixes the existing timing-sensitive input/frame tests with explicit synchronization and makes Jest discovery reliable from hidden Windows worktree paths.

No new PBI exists for this integration-only layer.

Limitations

• [rushd][WS0] Upstream engine prerequisites (in rush-lib) microsoft/rushstack#5895 still blocks command-independent plugin/phase graph construction and complete per-iteration runner lifetime. This layer only consumes an integration-owned real graph/request seam; it does not duplicate PhasedScriptAction, synthesize plugins, or construct an empty graph.
• Without an injected resolver, the standalone daemon starts and answers ping but rejects execution with the typed unsupported result.
• Warm-session recreation/reload is deferred to WS3; retained invalidation fails closed as workspaceRecreationRequired.
• Rush CLI parsing, launcher cutover, and requiresInProcess fallback consumption remain WS4 work.
• Each control connection runs one active request at a time so binary operation output is unambiguous; concurrent requests use separate connections and still share host scheduling/batching.

How it was tested

• node common/scripts/install-run-rush.js test --only @rushstack/rush-daemon-protocol --only @rushstack/rush-daemon-transport --only @rushstack/rush-daemon
• Repeated InteractiveRequestInputRouter, AsyncFrameHandler, and both wire integration suites three consecutive times.
• node common/scripts/install-run-rush.js check
• node common/scripts/install-run-rush.js change --verify