Keep PublishHelper.InPublishTab in step with the active tab (BL-16174)

[andrew-polk]

Switching from the Edit tab to Publish and asking for a BloomPUB preview sometimes threw
InvalidOperationException: Should not be creating bloom book while not in publish tab from
PublishHelper's constructor: the "Bloom had a problem" dialog appeared, the preview stayed
blank, and the Collection and Edit tabs were left greyed out until Bloom was restarted.

Cause

Bloom kept two records of "we are in the Publish tab", updated at different times:

• WorkspaceTabSelection.ActiveTab — the authoritative one, assigned in WorkspaceView.ChangeTab's PostponedWork.
• PublishHelper.InPublishTab — the static flag the book-staging code actually checks, maintained separately by PublishView.Activate()/Deactivate() from the SelectedTabChangedEvent subscriber.

The second is always updated later — after ActiveTab has already changed, and after however many
other subscribers have run. The log attached to the card shows the two disagreeing at the moment of
failure: PublishApi.MakeBloompubPreview's own guard (ActiveTab != publish → abort) let the request
through, so ActiveTab said "publish"; PublishHelper's guard fired, so the flag still said "not publish".

The same desync explains the second symptom. PublishView.Activate() is also what calls
SetTabsEnabled(true), the safety net that releases the Edit tab's save lock — a skipped activation
loses that too.

Fix

• WorkspaceTabSelection.ActiveTab becomes a property whose setter also sets PublishHelper.InPublishTab. One assignment, no window, one owner. This also clears the flag when a new collection's WorkspaceTabSelection initializes to the Collection tab — the static previously survived a collection switch.
• PublishView no longer writes the flag (comments at both sites point at the new owner).
• PublishView._isActive is now set before Activate()/Deactivate(), so a throw inside either cannot leave the latch stale and silently skip the next activation. Exceptions still propagate; nothing is swallowed.

Tests

New src/BloomTests/Workspace/WorkspaceTabSelectionTests.cs — 4 tests covering both directions and
the stale-static-across-collections case, each with a sanity check on the starting state.

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

Devin review

---

This change is 

[andrew-polk]

[Claude Opus 5 (1M context)] Consulted Devin on 2026-08-10, up to commit e2c4649515f8808dd0ed364217c6fea540929d69.

Devin ran three times, once per commit on this branch. Every run came back with no bugs and nothing flagged for investigation — the seven items on the final run are all Informational, so there are no findings mirrored as review threads here.

Two of the informational points were worth acting on, and did become commits:

• The new test fixture's summary comment implied that merely constructing a WorkspaceTabSelection is what clears the stale static after a collection switch. It isn't — the new WorkspaceView constructor's assignment is. Corrected, and the fixture is now [NonParallelizable] (2ce2afc).
• The comment on StageBookForBloomPubPreviewForTest claimed the staging guard means the publish tab has finished its setup. Since the flag now flips ahead of the SelectedTabChangedEvent subscribers, that is no longer what it proves; the e2e flow is safe because selectTab runs the whole switch synchronously inside its own awaited API call. Comment corrected (e2c4649).

The rest were noted and deliberately not acted on; they are in the preflight report for the developer, chiefly the observation that Bloom.Workspace now has a compile-time dependency on Bloom.Publish, with the alternative of making PublishHelper.InPublishTab a read-only property over a registered WorkspaceTabSelection.

CI (pr-automation) is green, and CodeRabbit does not review this repo (.coderabbit.yml sets auto_review.enabled: false).