Fix BL-16350 Cancel App Builder build when moving away from the Apps screen

[StephenMcConnel]

Cancels an in-progress App Builder (RAB) prepare / build / install when the user
navigates away from the Apps publish screen, so a long RAB build no longer keeps
running in the background after the user has moved on.

What it does

• Adds a per-action CancellationTokenSource in RabProjectService, claimed in
  TryBeginAction and torn down in ClearAction.
• New publish/rab/cancel endpoint (requiresSync: false, so it can run
  concurrently with the background action) that trips the token.
• Cancellation kills the running child-process tree (cmd.exe → rab.bat → Gradle/Java) so WaitForExit returns promptly, and stage-boundary checks
  stop the workflow between external processes.
• A cancelled action is reported as an informational "cancelled" message rather
  than a build failure.
• Front-end (useAppBuilderPublisherScreen) posts the cancel on the
  active→inactive sub-tab transition and on unmount (leaving the Publish tab).

Testing

• Added RabAppProjectTests covering cancel-stops-the-action and
  cancel-is-a-safe-no-op-when-nothing-is-running.
• Full RabAppProjectTests suite green (80/80).

Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-16350

Devin review

---

This change is 

[StephenMcConnel]

[Claude Opus 4.8] Consulted Devin on 2026-07-28 17:30 UTC up to commit 3c23233e2.

Result: clean — 0 Bugs, 0 Investigate flags. Devin raised 4 Informational items (not posted as threads; all assessed as non-actionable):

1. Cancel arriving just after a successful process exit skips the post-build state-save, leaving BuildNeeded true next time. Benign — the user navigated away, so discarding the unsaved build is acceptable (at worst a redundant rebuild if they return).
2. CancelActiveAction.Cancel() racing ClearAction.Dispose() beyond the guarded ObjectDisposedException. Practically nonexistent: the RunProcess cancellation registration's dispose already waits for any in-flight kill callback, so ClearAction runs only after the action has fully unwound.
3. Brief 'busy' flicker if the user returns to the Apps tab mid-cancellation, ending in the correct 'cancelled' message. UX only, not a correctness issue.
4. ~1-instruction window in TryBeginAction between claiming the slot and creating the CancellationTokenSource where a cancel would be a no-op. Requires starting an action and navigating away in the same microsecond; benign (the action simply runs).

Note: the more serious version of #2/#4 — ClearAction disposing a newly started action's CancellationTokenSource — was fixed in 3c23233e2 (free the slot last, after tearing down our own CTS), which is the commit Devin reviewed.

[StephenMcConnel]

[Claude Opus 4.8] Consulted Devin on 2026-07-28 21:25 UTC up to commit 133c4c8f1.

Result: clean — 0 Bugs, 0 Investigate flags. Devin raised 9 Informational items, all assessed as non-actionable:

• Confirmations (not issues): a cancellation-triggered OperationCanceledException reliably reaches the ReportCancelled branch rather than being reported as a build failure; and the single unmount-cleanup cancel trigger correctly covers both leaving Publish and switching sub-tabs (react-tabs unmounts the non-selected panel).
• Repeats of previously-assessed benign micro-window races: Cancel() vs ClearAction().Dispose() beyond the guarded ObjectDisposedException; the ~1-instruction gap in TryBeginAction before the token exists; a cancel arriving just after a successful process exit skipping finalization; and a brief 'busy' flicker if the user returns mid-cancellation. All require sub-microsecond timing or a deliberate quick return; worst case is a redundant rebuild. No user-visible harm.
• Minor/cosmetic (new): ReportCancelled sends the progress message with ProgressKind.Warning while its doc comment calls it 'informational' (styling vs wording mismatch); and a cancelled action still emits an actionComplete:failure websocket event — harmless because the Apps screen has already unmounted, so nothing is listening.

None warrant a code change.

[StephenMcConnel]

[Claude Opus 4.8] Consulted Devin on 2026-07-28 21:48 UTC up to commit 98e0d88f5.

Result: 0 Bugs, 1 Investigate, 9 Informational.

• Investigate (posted, thread left open for a decision): the RAB installer download during a first-run Prepare isn't cancellable — #discussion_r3669416271. Real gap (the HTTP byte-copy loop has no token check), but a first-run-only path outside this PR's original build-cancellation scope; flagged for a fix-here-or-follow-up decision.
• Informational — no action: most repeat previously-assessed benign micro-window races and confirmations. Note that two of them (ReportCancelled Warning-vs-comment, and cancelled action emitting failure) describe code this very commit fixed — Devin's analysis lagged 98e0d88f5; both are now resolved. One more references the transition effect already removed in 8d995a10e.
• CI: pr-automation and track/set-waiting both green.

[StephenMcConnel]

[Claude Opus 4.8] Consulted Devin on 2026-07-28 22:00 UTC up to commit f81d47ad7. CI (pr-automation, track/set-waiting) green.

0 Bugs, 1 Investigate, 10 Informational. The Investigate flag is the same installer-download item (thread, resolved) that f81d47ad7 fixed — Devin's pattern match re-fires because the fix checks ThrowIfActionCancelled() in the copy loop rather than threading the token into HttpClient/GetAsync. Functionally the download is now cancellable during active streaming; the only residual is a stalled-connection / blocked-read edge case still bounded by the 30-min timeout. Deciding with the developer whether to leave the loop-check fix as sufficient or thread the token fully. Informational items are the previously-assessed benign repeats/confirmations (several describe already-fixed/removed code — Devin lagging the recent commits).

[StephenMcConnel]

[Claude Opus 4.8] Consulted Devin on 2026-07-28 22:34 UTC up to commit e1941e3b0. CI green; full suites green (C# 2946 passed/0 failed, front-end 568 passed/0 failed).

Devin reports 1 Bug + 1 Investigate, but both are lagging re-reports of issues already fixed in e1941e3b0 itself — its bug text still describes the file being 'left on disk (CopyRabInstallerDownloadStream)', but that commit moved the write into WriteRabInstallerDownloadToFile with a .partial temp file that is moved into place only on a complete download and deleted on cancel/failure (regression test WriteRabInstallerDownloadToFile_CancelledMidDownload_LeavesNoLeftoverFile proves nothing is left behind). Both have resolved threads already (bug, investigate); not re-posting duplicates. Stopping the re-review loop here since the findings are addressed and verified.

[hatton]

I had written:

while it's building you can't do anything except cancel.

But Claude says

This change makes Bloom cancel that in-progress action the moment you leave the Apps screen

By my instruction, I did not mean to auto-cancel. I meant that the user's only option should be to explicitly cancel the process. In the absence of a button, they can click on the "X" in the upper right. Can we do that?

[StephenMcConnel]

I misunderstood the instructions. I'm starting over on another branch.