Detect Windows Dev Drive during install/first-run and offer it as the storage/data root

## What problem are you trying to solve?

On Windows, the Copilot App stores everything under `%USERPROFILE%\.copilot` on
the OS drive (typically NTFS `C:`). That directory holds the most I/O-intensive
assets in the product:

- `repos\` — every cloned repository
- `copilot-worktrees\` — a git worktree per session
- `session-state\`, `chats\`, `workspaces\`, `pkg\`, `media-cache\`
- `data.db` (hundreds of MB) + rolling `data.db.pre-update-backup-*` copies,
`session-store.db`, and WAL files

If the machine has a **Dev Drive** (ReFS volume), install/first-run never
detects it and never offers it. Users end up running the heaviest part of the
product on the slower, often-fuller OS drive, and manually clone side repos onto
the Dev Drive to compensate — which the App then doesn't manage as its own data.

This is especially relevant for Copilot specifically, because a large share of
what it does is **small-file I/O**: grep/glob searches, reading many files to
build context, dependency installs, and builds. On Windows those are exactly the
operations most slowed by Defender real-time scanning — and Dev Drive
(ReFS + performance-mode antimalware + block cloning) is **Microsoft's
recommended fix** for that workload.

Measured gains for these workloads (Microsoft + independent benchmarks):
~14–28% faster .NET builds (copy-on-write / block clone), ~20–30% faster
`git clone` and package restore.
Refs: [Engineering@Microsoft](https://devblogs.microsoft.com/engineering-at-microsoft/dev-drive-and-copy-on-write-for-developer-performance/),
[Visual Studio blog](https://devblogs.microsoft.com/visualstudio/devdrive/).

## Proposed solution

During install and/or first-run on Windows:

1. **Detect Dev Drive volumes** — e.g. `fsutil devdrv query `, or
enumerate `ReFS` volumes and check the Dev Drive trust flag.
2. **If one exists, offer it as the storage/data root** for App data (repos,
worktrees, caches, DBs), presented as *"recommended for performance on
Windows,"* with the OS-drive default as the fallback.
3. **Persist the choice** as a first-class configurable storage-root setting so
it isn't hard-coded to `%USERPROFILE%`.
4. **Provide a relocate/migrate action** so existing installs can move their
data root onto a Dev Drive after the fact (DB, repos, and worktrees moved
safely).

### Important trade-off to surface (not a blocker)

There is a **known interaction** with the local sandbox on Windows, documented
in github/copilot-cli#3712: the Windows Bind Filter (BFS) that enforces sandbox
policy does **not** work correctly on ReFS, so a working directory on a Dev
Drive plus the local sandbox currently fails with a `backend_error`. The
detection UX should be honest about this — if a user relies on the local
sandbox, warn that the sandbox and a Dev Drive data root are currently
incompatible and let them choose deliberately. For users who don't use the local
sandbox, the performance win is immediate and free.

## Workflow impact

Affects any Windows developer with a Dev Drive (an increasingly common,
Microsoft-recommended setup). Today they either eat the OS-drive/NTFS penalty on
the App's heaviest workloads, or hand-roll workarounds the App doesn't track.
Smart detection + a recommended default would give them the documented
performance gains automatically, and keep the App's repos/worktrees/caches in the
right place without manual intervention.

This complements #208 (separate storage locations for repos vs worktrees): that
request is about manual path granularity; this one is about smart detection and
a recommended default. Both point at the same underlying need — first-class,
performance-aware storage configuration on Windows.

## Installation context

Per-user Windows desktop install. Real setup this came from: Dev Drive at `D:`
(ReFS, ~250 GB) sitting idle while `C:\Users\\.copilot` on NTFS `C:` was
down to ~60 GB free and holding all repos, worktrees, and multiple hundred-MB DB
backups.

## Additional context

- Related: #208 (separate storage locations for worktrees vs main repo).
- Related: github/copilot-cli#3712 (ReFS / Dev Drive local-sandbox Bind Filter
limitation on Windows).
- Prior art: Visual Studio and `git`/npm/NuGet cache guidance already steer
developers to place repos and package caches on a Dev Drive; the Copilot App
would benefit from the same defaults.

Start with the Windows per-user install and first-run flow, then trace how data currently defaults to %USERPROFILE%\.copilot. Review the Dev Drive detection options named in the issue, including fsutil devdrv query and ReFS volume enumeration. Done means offering and persisting a Dev Drive root, supporting safe relocation of the listed data, and surfacing the local-sandbox incompatibility.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.