Make the publish upload modal on the publish-tool switcher too (BL-16654)

[andrew-polk]

Uploading a book to BloomLibrary already greyed out the main workspace tabs, but left the publish-tool buttons (PDF & Print, Web, BloomPUB, …) live. One click tore down the Web screen, which took its Cancel button, its progress log and its eventual "Your Book on BloomLibrary.org" link with it while the upload carried on invisibly; coming back offered an enabled Upload button, so a second concurrent upload of the same book was reachable.

Rather than give the Publish tab a second, weaker notion of "busy", this reports the existing lock to the browser: WorkspaceView.GetTabInfo now sends navigationLocked alongside the tab states, and PublishTabPane vetoes tool switching and greys out the other tools while it is set. Because that is the same flag C# already toggles in a try/finally around the upload, the publish tools unlock at the moment the upload really finishes or is cancelled — not when the browser guesses it has. The front end's own isUploading is cleared as soon as Cancel is clicked, and by any error line in the progress log, both of which would have unlocked too early.

The Apps tool gets this for free and now shares one path, so its appsBusy state and the onBusyChange callback threaded down through AppPublisherScreen are gone. As a side effect the lock now survives that screen remounting mid-action.

SetTabsEnabled stays a single shared flag rather than becoming a count. That was a deliberate call: with the tool switcher locked as well, the user can no longer start a second publish operation while one is running, so the overlap the old RabPublishApi comment worried about is unreachable. That comment is updated to say so. (Verified there is no programmatic navigation to the Publish tab — the only ChangeTab(WorkspaceTab.publish) call site is a user click on the top bar, which is itself refused while the tabs are disabled — so PublishView.Activate()'s unconditional re-enable cannot fire mid-operation.)

Deliberately not in scope, per decisions on the card: no tooltip/new localized string on the disabled buttons (matches how Apps behaves today), no re-entrancy guard on the upload endpoint, and no change to ePUB/BloomPUB/PDF preview generation (those abort cleanly when you leave, rather than needing to block).

Not verified in a running Bloom: the greying-out has not been watched during a real in-flight upload.

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

---

This change is 

---

Devin review

Devin review

[andrew-polk]

(Claude Opus 5 from Andrew Polk's machine during preflight)

Consulted Devin on 2026-08-06 up to commit 6a97f74e133125cb4cd9c2ed7183d798b5552193.

Devin was run twice this session, once per commit. Against a414056cca it raised one Investigate flag — that the publish tools could all grey out at once when no tool is yet selected. That was real, and 6a97f74e13 fixes it; the thread has the details.

The re-review of 6a97f74e13 raised one Bug, that dialog bookkeeping could release the upload's lock mid-upload. Assessed as a false positive: both dialogs it named only post editView/setModalState when their mode is Mode.Edit, and the Publish tab doesn't use that mode. Reasoning is on its thread. It also re-emitted the already-fixed Investigate flag verbatim against the pre-fix line numbers, so that repeat is stale rather than a second finding.

Six informational items in total across the two runs, not mirrored here (low signal). CodeRabbit is switched off in this repo by .coderabbit.yml, and there is no PR build/test CI, so the local suites stood in: TypeScript 667 passed, C# 3031 passed with one opt-in Reading-App-Builder test failing purely for lack of a local toolchain.

[andrew-polk]

(Claude Opus 5 from Andrew Polk's machine during preflight)

Consulted Devin on 2026-08-06 up to commit 40ce746790bdbb569108d9877c0220a2e525127a.

Two more rounds since the note above, and the branch has been squashed to a single commit (so earlier commit shas on this PR no longer exist; the review threads survived and are all resolved).

Round 3 (ea033c412f) raised two real findings, both fixed in 40ce746790: the new useWorkspaceTabInfo hook used arrow-constant syntax where src/BloomBrowserUI/AGENTS.md asks for function syntax — a documented rule I had missed — and the publish-tool lock could stick if one of the two pre-upload API calls died at the transport level, which now clears via an error callback.

Round 4 (40ce746790) raised one genuinely new question, whether every exit from the upload-collision dialog clears isUploading. Confirmed that they all do, via the dialog's onCancel, including the uploadAfterChangingBookId failure path it specifically asked about. Not an issue; reasoning is on its thread.

Worth knowing when reading Devin's page for this PR: it re-emits findings against the very commit that fixes them. Both round-3 findings, and the two findings from earlier rounds, still appear in the round-4 results even though each was already fixed or refuted in the commit analysed. Every finding across all four rounds now has a documented outcome on a resolved thread here — treat those threads, not Devin's page, as the current state.

One finding has now been reported four times and refuted three: that dialog bookkeeping can unlock the tools mid-upload. It remains a false positive (TopicChooserDialog and ConfirmDialog both gate the editView/setModalState post on Mode.Edit, and the Publish tab doesn't use that mode), and since this round it is doubly moot — the Web screen's own upload signal is OR-ed into the lock, so even a cleared C# flag would keep the tools locked during an upload.

[JohnThomson]

@JohnThomson reviewed 9 files and all commit messages, and resolved 5 discussions.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on andrew-polk).