rushd: WS3/WS4 integration with Reporter prerequisites

[Sean Larkin (TheLarkInn)]

What this adds

An opt-in Rush build daemon that keeps configuration and the build graph in memory between commands. Repeated builds can reuse that setup instead of starting the engine from scratch.

Implements WS3 (#5898) and WS4 (#5899) of #5894, with Reporter prerequisites from #5858. Existing rush and rushx behavior stays unchanged.

Developer outcomes

• Run builds through rush-client and supported package scripts through rushx-client.
• Start the daemon automatically, reuse it across commands, and shut it down when idle.
• Queue competing requests and share overlapping build work while keeping each client's output and result separate.
• Reload configuration or restart after dependency, environment, or Rush-version changes.
• Inspect and manage the daemon with start, stop, restart, status, and logs commands.
• Keep selected workers and results warm, with configurable idle and memory limits.

The PR also fixes shared Windows lock cleanup, shell/environment handling, and request-selection isolation. Those fixes affect ordinary Rush commands too, not just daemon execution.

Trying it

Install a matching daemon-capable package set and select its Rush version in rush.json, then opt in:

RUSH_DAEMON=1 rush-client build --to my-project
rush-client daemon status

The client starts the daemon if needed. Use --no-daemon for in-process execution. CI stays in-process unless explicitly enabled with RUSH_DAEMON=1.

Merging this PR does not publish those packages. See the client guide and environment-variable reference for setup and controls.

Current limits

• Unsupported configurations—including external Rush plugins and phased-build .env initialization—fall back before execution. A successful build alone does not prove it used the daemon.
• Keeping Rush warm does not automatically keep Heft, TypeScript, or webpack processes alive. Persistent Node workers require explicit daemonIpc configuration and a compatible worker implementation; this mode is unsharded and non-cacheable.
• daemon.watch observes files; it does not start builds automatically. Memory limits are best-effort, not hard process-tree limits.
• The daemon runs as the same local user. It is not an elevated service or a sandbox for untrusted clients.

Making ordinary rush/rushx use the daemon by default is the later WS5/Rush 6 change (#5900). This PR does not make that switch.

Review scope

This branch includes Reporter work as well as daemon integration. The file-level review map separates exact inherited files from integration and mixed changes. Review fixes and repository-wide formatting are in 1b4f89ae37.

The environment reference is included here; publishing it to the separate website repository remains a release follow-up.

[Sean Larkin (TheLarkInn)]

Published 6a3fc846e39dfa32ee421ce896405aad87a9856b with a test-only correction for a demonstrated IPC-retention pressure precondition defect.

A real working-set trim of the verified fixture-owned Windows 24 daemon reduced RSS between allocation sizing and admission release. Combined RSS remained below the 512 MiB budget, so maintenance correctly retained both projects while the fixture incorrectly expected one. This proves the fixture defect, not the precise cause of the uninstrumented hosted failure.

The same public IPC request now remains admitted while the fixture measures actual RSS, performs at most one bounded adjustment, and verifies real pressure plus single-runner headroom before releasing admission. All four real policy cases, exact retained/watched/generation assertions, memory budgets and existing deadlines remain unchanged. Production and API code are unchanged.

The same controlled native counterexample failed before and passed after. Normal Windows 24, Windows 26 and Linux each passed 11 focused cases, including all four real retention cases; build/types/lint passed.

Fresh full CI run 34574532587 is in progress on the new head. The previous Windows 24 failure is preserved, not waived or repeatedly retried. Independent approval and prerequisite landings remain required.

[Sean Larkin (TheLarkInn)]

Published both fixture corrections together at e380ab28ec8d38bd9b193a6c01850d1737fc6798 (atomic-publication commit 72219c9 plus the daemon-setup ownership correction).

The Linux 24 failure was a created-but-not-completely-written release JSON file. Allocation, adjustment, release, cancellation and fixture inputs now publish a closed owned temporary sibling atomically; event logs use complete NDJSON frames and current request identity. Malformed completed data still fails explicitly.

The Windows 26 failure exposed unowned initialization after a setup-hook timeout. Teardown now cancels and joins late creation and disposal before using the fixture, preserving both original setup and cleanup errors. A forced 5,000 ms timeout still fails its case, without the secondary undefined-disposal error or leaked host/folder.

The exact nine-path union is test/helpers and two type-none change notes only. Production, APIs, configuration, defaults, memory budgets, original retention assertions and all existing deadlines are unchanged.

On the actual combined head, Linux 24 passed app 36/36 and daemon 29/29; one full uninstrumented serial Windows 26 qualification passed app 36/36 and daemon 14/14. This closes the earlier local full-run qualification gap; it does not claim the prior intermittent startup/timing cause was eliminated. Previous Windows 24 evidence is reused only by exact source/runtime identity, not represented as a new combined run.

Hosted CI verified September 11 at 11:29 UTC: 34584314860 attempt 2 passed all six complete platform workflows and every current check on e380ab28. A single evidence-backed Windows 24-only retry succeeded after nested build-setup hook timeouts; the other five successful results were retained. No source, deadline, assertion or quality gate changed for that retry. Earlier failures remain archived and their timing cause is not claimed eliminated. All six remaining PRs are now CI-green, but independent approval, prerequisite landings and the proper #6019 landing base remain required.