File changes list has no scroll when expanded with many files

[gregpriday]

Summary

When a worktree card's details section is expanded and there are many git changes, the "Changed Files" list renders at full height with no scrolling. The list grows unboundedly, pushing other card content far off-screen and making the list itself impossible to navigate without scrolling the entire sidebar.

Problem Statement

Users with active worktrees (especially the root worktree on large projects) often have 20–100+ changed files. When they expand the details section to inspect those changes, the file list expands to show every file at once with no height cap. This:

• Pushes the worktree card path footer and other cards completely off-screen
• Forces the user to scroll the full sidebar rather than the list itself
• Makes the card feel broken and unusable when there are many changes

There is no current workaround — users cannot scroll within the file list.

Current Behavior

The FileChangeList component renders in an unconstrained flex flex-col or space-y container. The parent expanded panel in WorktreeDetailsSection also has no height cap. WorktreeDetails passes maxVisible={worktree.worktreeChanges.changes.length} — intentionally showing all files — but provides no scrollable viewport for them.

Relevant code:

• src/components/Worktree/WorktreeDetails.tsx#L190-L199 — FileChangeList rendered with maxVisible set to the full count, no scroll container
• src/components/Worktree/FileChangeList.tsx#L261-L278 — flat list render with no max-height or overflow
• src/components/Worktree/FileChangeList.tsx#L221-L248 — grouped folder render, also no max-height or overflow
• src/components/Worktree/WorktreeCard/WorktreeDetailsSection.tsx#L70-L91 — expanded panel container, no height constraint

Desired Behavior

When the file changes list is expanded, it should be scrollable within a bounded height so that:

• The card remains a reasonable size regardless of how many files are changed
• Users can scroll through the file list without affecting the rest of the sidebar
• The path footer and other worktree card content remain visible without excessive scrolling
• The transition from "few files" to "many files" is smooth (the list shouldn't feel cramped with 3 files, but should cap at a reasonable height for 50+ files)

Acceptance Criteria

• The expanded file changes list has a maximum visible height and is scrollable when the number of files exceeds that height
• With a small number of changes (≤ ~8 files), the list renders at natural height without a fixed-height box
• With many changes (20+ files), the list does not overflow the card or push other content off-screen
• Scrolling within the file list does not scroll the entire sidebar
• Both the flat and grouped-by-folder list layouts are constrained
• The scrollable area is visually clear (user can see there is more content below)

Edge Cases & Risks

• Very long folder-grouped lists where the group header rows must also scroll within the constrained area
• The root worktree card is typically taller than branch worktrees — the max-height should feel proportionate in both contexts
• Sidebar resize: the height constraint should work at narrow and wide sidebar widths