fix(tabs): keep the tab in front after a save prompt and dim tab navigation it cannot use

[datlechin]

Summary

Four defects in tab selection and window key state, found while investigating #2524. Builds on #3061 (merged), which touched the same menu validation and connection-switch code.

Fixes

1. Closing a background tab with unsaved work landed on its neighbour. Closing a tab that holds unsaved work selects it first so the save alert points at it. Cancel put the selection back, but Save and Don't Save left it on the closed tab's neighbour, a tab the user never chose. A clean background tab never moved the selection at all. Every answer now restores the tab the user was on, unless they picked another tab while the close was pending (a save can wait on the server with the strip still live), in which case their newer choice stays. Closing the tab in front still lands on its neighbour, since the tab it would restore is gone. The confirmation is injectable on MainContentCommandActions so the paths are tested without a modal.
2. Show Previous Tab, Show Next Tab and Select Tab 1 to 9 were enabled in Agent mode, validated on isConnected alone, and quietly changed the selected tab behind the conversation (the strip is not drawn there).
3. The same items were enabled with nothing to do: all of them with one tab (no strip, and Select Tab 1 reselects the tab in front), and Select Tab N with fewer than N tabs. Validation now reads the open tab count (MainContentCommandActions.openTabCount, which existed and was unused) and the numbered item's own tag.
4. The window's first connection kept isKeyWindow after the first switch away from it. applySelectedWorkspace resigned lastActiveCoordinator, which only a switch sets, while the first connection is made key by the window itself. So the first switch had nothing cached to resign, the outgoing coordinator never scheduled the eviction that frees its row buffers, and its row data stayed in memory. The switch now resigns every other coordinator that still reports itself key.

Tests

• CommandActionsCloseSelectionTests: Don't Save and Cancel on a background tab keep the tab in front; a tab picked while the close was pending stays in front; closing the tab in front still lands on its neighbour. The dirty fixture is an emptied file, not a reopen candidate, so the suite never writes to the Recently Closed Tabs history of whoever runs it (a precondition asserts that).
• TabNavigationMenuValidationTests: stepping needs two tabs and browse mode; Select Tab N needs an Nth tab, and Select Tab 1 (the real menu item's tag) dims with one tab.
• WorkspaceSwitchKeyStateTests: the first switch resigns the first connection and schedules its eviction; switching back hands key status back.
• Neighbouring suites: 194 cases across 16 suites, all passing locally.

Each new test fails against the code before the fix: without the restore, Don't Save selects the neighbour; without the new arms, the items stay enabled; without the resign loop, the first coordinator stays key.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
TablePro	🟢 Ready	View Preview	Sep 23, 2026, 8:36 AM

💡 Tip: Enable Automations to automatically generate PRs for you.