[rush] rushd: show continuing-work progress and lock ownership after early failure #6158

Summary

Enhancement: make continuing work and repository-lock ownership visible after a daemon build reports failure early.

The early failure result is useful. Keeping the native Rush execution lease while unaffected operations finish is also correct. The confusing part is the gap between "my build command exited" and "this workspace is safe for dependency installation." A one-time list of continuing operations gives no subsequent progress or positive completion signal in that terminal.

This requests clearer UI and machine-readable status, not earlier unlocking or a change to failure exit codes.

Before

Example output below is illustrative; project names and workspace details are anonymized:

rush build: FAILURE ... 6 independent operations continue in rushd:
  project-a (build), project-b (build), project-c (build) +3 more

# The client exits 1.
# The developer needs to run rush install, but must first establish
# whether background builds are still progressing or the lock is stuck.

An automation client ends up inspecting processes or polling a lock file outside Rush. Transport readiness is not the same thing as an idle workspace or released execution lease.

After (proposed)

Keep the early failed result, but explain what still owns the workspace and offer a read-only progress surface. For example, extend daemon status with a proposed --watch mode:

rush build: FAILURE (exit 1)
Workspace remains busy: 6 continuing operations hold the repository lock.
Monitor: rush-client daemon status --watch

# In the proposed monitor:
Workspace: draining | repository lock: held | draining for: 00:45
Running: project-a (build), project-b (build)
Queued behind continuing work: project-c (build)
...
Workspace: finishing cleanup | repository lock: held
Workspace: idle | repository lock: released
Dependency installation can now acquire the repository lock.

Use the same explanation in daemon-aware command-admission/wait messages. A changing remaining-operation count and bounded list of names are enough; do not require verbose logs.

Details

In one anonymized session, six unaffected operations continued for approximately 167 seconds after the early failure result. Some downstream work started only after its prerequisites completed. An external waiter later spent approximately 85 seconds waiting for the lease; the subsequent installation itself took approximately 35 seconds.

Those intervals overlap: the external waiter began partway through background draining. We deliberately waited outside rush install; these are not measurements of native install lock-acquisition delay. Investigation did not establish a prolonged lock hold after the final work completed. The actionable issue is that normal draining looked like a stuck lock.

Acceptance criteria

• Preserve early failure reporting and its nonzero exit code; do not keep a failed client attached solely to monitor unrelated work.
• Expose workspace state separately from daemon transport readiness: executing, draining, cleanup, and idle.
• Show whether the execution lease is held, the remaining running/queued work, and elapsed draining time. Refresh on state changes with bounded periodic output for non-interactive clients.
• Include machine-readable equivalents for automation; do not require parsing a lock-file pathname or human progress text.
• Identify completion from actual lease release after operation/child cleanup, not merely from a zero operation count.
• Timestamp the transition to idle. If a later command waits, distinguish that wait from its own execution time.
• Do not automatically start installation, cancel continuing builds, force-unlock, or promise the workspace cannot be claimed by another command after an idle snapshot.

Related: #5899 (CLI command surface), #6075 (daemon error UX). This is distinct from #6071: here real work remained; this is not a report of output backpressure retaining a lease after execution finishes.

Environment

No internal source paths, project names, identities, process IDs, or raw logs are included.