[rushd][WS4] CLI client & command surface

Start by reading the dependent issues #5896, #5897, and #5898, then examine the rush-client-core and rush-cli-client package entry points plus the existing rush and rushx commands. Verify the rush.json daemon block, routing precedence, daemon subcommands, graph protocol, and standalone rushx behavior against the listed acceptance criteria. Done means opt-in client behavior, validated configuration, correct streaming and exit handling, gated graph commands, and green CI tests.

Build the separate CLI client package/bin (@rushstack/rush-cli-client on @rushstack/rush-client-core) and its command surface — fallback/opt-in routing, rush daemon subcommands, the rush.json daemon config block + env overrides, an experimental rush daemon graph reference client, and a standalone rushx-equivalent bin — all opt-in until cutover.

Depends on: #5896; #5897; #5898

Scope

• rush-client-core + rush-cli-client bin. Connect/forward/pump, the request envelope (argv, cwd, env, columns, colorLevel), stream pumping, exit-code relay, and cancel-on-signal — with no SIGWINCH forwarding (the client owns width/resize).
• Fallback/opt-in routing. Decide daemon vs in-process per invocation from RUSH_DAEMON, --no-daemon, rush.json config, CI detection, and the never-daemonize list (routing to today's in-process path otherwise).
• rush.json daemon config. A validated daemon block (enabled, idleTimeoutSeconds, autoStart, watch, queueTimeoutSeconds, plus the WS3 warm-set knobs) with RUSH_DAEMON* env overrides.
• rush daemon subcommands. start|stop|restart|status|logs (themselves never-daemonized); status surfaces warm-set + lifecycle info (uptime, PID, reload tier, warm projects, memory) and logs streams the daemon log.
• Experimental rush daemon graph. Behind RUSH_DAEMON_EXPERIMENTAL=1, show/status/scope-in/scope-out/invalidate/watch/pause/resume over the warm graph, serving as a reference "third client" that consumes only structured events.
• Standalone rushx-equivalent. Run the cwd project's package script with the same auto-start/forward behavior; it becomes rushx at cutover (WS5).

Acceptance criteria

• The client connects, sends the request envelope, pumps stdout/stderr/stdin, and relays the daemon's exit code; Ctrl+C cancels the request; SIGWINCH is handled client-side and not forwarded; a sample rush build via the client is behaviorally equivalent to in-process (full matrix in WS5).
• Each routing input (RUSH_DAEMON, --no-daemon, config, CI, never-daemonize) selects the correct path with a documented precedence order; CI defaults to in-process (no auto-start) unless explicitly opted in.
• The rush.json daemon schema is published and validates the block (rejecting unknown/invalid values) with precedence env > config > default.
• Each rush daemon subcommand acts against a running (or absent) daemon with correct exit codes; status reports warm-set + lifecycle info and logs streams the daemon log (see WS5).
• The experimental rush daemon graph verbs operate over the warm graph via the protocol only (no rush-lib-internal calls), consume only the presentation-free event contract, and stay gated off unless RUSH_DAEMON_EXPERIMENTAL=1.
• The standalone rushx-equivalent resolves the project by cwd, forwards with auto-start, and matches today's rushx output/exit code for a sample script.
• rush-client-core has no rush-lib dependency and commits its API Extractor report; everything ships opt-in until cutover; tests green in CI.

Part of #5894.