[rushd][WS0] Upstream engine prerequisites (in rush-lib)

[bmiddha]

Land the watch-mode overhaul and adapt in-repo plugins so the engine exposes a stateful, warm-able operation graph the daemon can own.

Depends on: #5378 (provides the stateful IOperationGraph)

Scope

• Merge the watch-mode overhaul ([rush] (BREAKING CHANGE) Overhaul watch-mode to facilitate orchestration #5378). Land the stateful IOperationGraph (setEnabledStates, scheduleIterationAsync, executeScheduledIterationAsync, invalidateOperations, abortCurrentIterationAsync, closeRunnersAsync), OperationGraphHooks (onIdle, onExecutionStatesUpdated), IPCOperationRunner, and the reworked ProjectWatcher — replacing the disposable OperationExecutionManager with a graph that persists across iterations.
• Migrate in-repo plugins. Move CacheableOperationPlugin, ShardedPhaseOperationPlugin, OperationResultSummarizerPlugin, ConsoleTimelinePlugin, PhasedOperationPlugin, IPCOperationRunnerPlugin, rush-serve-plugin, rush-bridge-cache-plugin, and rush-buildxl-graph-plugin onto the new hooks.
• One warm full-workspace graph. Build the graph over all workspace projects with a client's selection applied as an enabled subset (includeAllProjectsInWatchGraph) so the daemon keeps a single warm graph and scopes it per request.
• Per-iteration runner lifetime. Lift the persistent-vs-one-shot choice out of static IPCOperationRunnerPlugin construction into a per-iteration host decision — keep hot runners resident for warm projects; tear cold ones down immediately at operation completion.
• Follow-up (non-blocking). Converge rush-lib's OperationGraph onto the standalone @rushstack/operation-graph library.

Acceptance criteria

• The stateful IOperationGraph and OperationGraphHooks are merged and exported, with the public API captured in the committed rush-lib.api.md.
• All existing phased-command and watch-mode behavior is preserved; updated snapshots are intentional and reviewed.
• Every in-repo plugin compiles and passes its tests against OperationGraphHooks (no plugin depends on a removed/renamed hook except through the optional compat shim in WS5); cache, sharding, summary, and timeline outputs are unchanged.
• A full-workspace graph can be built once and an arbitrary selection enabled via setEnabledStates without rebuilding; disabled projects stay resident (watchable/invalidatable) but unscheduled.
• The host can choose persist vs one-shot per operation per iteration (default unchanged when unspecified); a non-persistent runner is torn down immediately at its operation's completion, before downstream operations run.
• (Follow-up, not on the critical path) rush-lib consumes @rushstack/operation-graph with no behavioral change.
• Breaking hook renames/relocations are recorded in the WS5 migration guide + API changelog; new engine behavior ships opt-in / dead-code until cutover; unit/integration tests green in CI.

Part of #5894.

[dmichon-msft]

There are some complexities to the rushd vs. watch mode interactions vis-a-vis which phases are in scope. We don't currently have an "all possible phases" mode, and the dependency graph nodes and edges are both allowed to vary depending on the command being invoked (via plugins modifying the graph, notably).