feat(sidebar): collapsible terminal tab list under branch rows

[paulovitin]

Summary

Adds a collapsible list of a branch's terminal tabs directly under each branch row in the left sidebar, so you can see and jump to a worktree's open terminals without opening the tab bar.

• New tabsExpanded flag on BranchState, persisted via save_repositories (same mechanism as sessions).
• BranchTabList renders one subitem per terminal — status dot (busy / idle / unseen / error / question) + terminal name. Clicking a subitem calls navigateToTerminal (switches branch context + focuses the terminal). Active terminal is highlighted.
• Subitems only appear when a branch has more than one terminal (single-terminal branches stay compact).
• Caret is a visual indicator; the whole branch row is the affordance:
  • Clicking an unfocused branch -> focuses it and opens the list (never collapses on a focus-switch).
  • Re-clicking the already-focused branch -> toggles (so it can be closed).
• Sub-level visual: list inset so its background starts where the parent branch icon ends; group-hover lifts the whole branch + tabs block as a unified card.

Test Plan

• npx tsc --noEmit clean
• npx vitest run — full suite green (4149 passed)
• Store: toggleBranchTabsExpanded / setBranchTabsExpanded (toggle, set, idempotent open, no-op on unknown, debounced persist)
• Component: chevron only with >1 terminal; one subitem per terminal when expanded; re-click active toggles; focus inactive opens (never toggles); single-terminal branch neither opens nor toggles
• Manual: verify persistence across app restart, status-dot colors, and group-hover rendering

🤖 Generated with Claude Code

[paulovitin]

@sstraus what do you think about this feature?
Many of coworkers request this because they use a lot of tabs hahaha.

[sstraus]

@paulovitin in reality I was thinking about the real usefulness of having the tabs also reported in the sidebar. With many open projects at the same time the list may explode. If you show them by clicking there is no difference to opening it and checkign the tabs.

In particular, adding elements that reduce the space for the branch name is potentially a problem, especially for those who have small monitors. I'm refering to the arrow to open the collapsed area.

If everything is called main, it's simple, but if the branch names start with feat/branch name then the space becomes very little, especially if there are many changes.

I haven't had time to try it in production yet. Shall we put it behind feature flag?

[paulovitin]

@paulovitin in reality I was thinking about the real usefulness of having the tabs also reported in the sidebar. With many open projects at the same time the list may explode. If you show them by clicking there is no difference to opening it and checkign the tabs.

In particular, adding elements that reduce the space for the branch name is potentially a problem, especially for those who have small monitors. I'm refering to the arrow to open the collapsed area.

If everything is called main, it's simple, but if the branch names start with feat/branch name then the space becomes very little, especially if there are many changes.

I haven't had time to try it in production yet. Shall we put it behind feature flag?

My thinking was that tabs provide a quick overview of active work across projects without having to switch context into each one, but I agree the value decreases as the number of open projects grows. I also agree that branch visibility is probably more important than tab visibility. If we end up truncating branch names to make room for disclosure controls, that's likely a net negative.

Im fine putting this behind a feature flag or a in the config settings. That would let people try it in real world workflows and give us feedback before we commit to the UX permanently.

What do you prefer?

[sstraus]

I merged it in the new release behind a feature flag. let's see how it works. Thx.