feat: Worktree management UI in Settings

[PureWeen]

Problem

PolyPilot creates worktrees for repo-centric sessions (multi-agent groups, PRs, etc.) but has no UI to see or clean them up. Over time, dozens of stale worktrees accumulate consuming tens of GB of disk space. Users have no way to know which worktrees exist, which have active sessions, how much disk they use, or how to clean them up.

Real-world example: 54 worktrees on disk, 26 with no active sessions, ~37 GB reclaimable. Currently requires manual terminal investigation to identify and clean.

Proposal

Add a "Storage" section to the Settings page (desktop only) that shows all managed worktrees grouped by repository.

Per-repository card

• Repo name, URL, total disk usage, worktree count
• Collapsible to show individual worktrees
• "Clean All Unused" button — deletes all worktrees with no active sessions
• "Delete Repository" button — removes bare clone + all worktrees

Per-worktree row

• Branch name
• Status badge: Active (has sessions) / Unused / Dirty (uncommitted changes)
• Number of active sessions using it
• Disk size
• Delete button (disabled with tooltip if sessions are active)

Backend additions

• WorktreeStatus record in RepoManager with session count, dirty file count, per-worktree disk size
• GetWorktreeStatusesAsync method that cross-references active-sessions.json working directories with worktree paths and checks git dirty state
• Active-session guard preventing deletion of in-use worktrees

Implementation Plan

1. Add WorktreeStatus model and GetWorktreeStatusesAsync to RepoManager
2. Add "Storage" nav item + settings group to Settings.razor
3. Add scoped CSS for repo cards, worktree rows, status badges
4. Wire delete buttons to RepoManager.RemoveWorktreeAsync / RemoveRepositoryAsync with confirmation dialogs and status toasts

Context

This came from a hands-on cleanup session where we manually identified 26 unused PolyPilot worktrees (~37 GB), verified none had active sessions or unpushed work, and deleted them. The experience highlighted that this should be a first-class UI feature.