fix(projects): match git root when Windows drive letter case differs

[NicoKiaru]

Problem

On Windows, the Projects page shows git-repository groups with "0 projects", and the sessions of those projects can't be reached from there.

Claude Code can record a project's path with a lowercase drive letter (f:/code/journal), while git rev-parse reports the git root with an uppercase one (F:/code/journal). For example, from /projects:

path: f:/code/UNIGE/journal   git_root_path: F:/code/UNIGE/journal   session_count: 51

groupProjects() in frontend/src/lib/utils/grouped-projects.ts compares the two with an exact string match after normalizing backslashes, so the root project is never found. With no root and no nested projects, the group ends up with totalProjects === 0. It still goes into gitRoots, which renders as an empty "0 projects" card.

Fix

• normalizePath() now uppercases a leading Windows drive letter, alongside the existing backslash → slash normalization. Drive letters are case-insensitive on Windows, so this is safe. The rest of the path is left as is.
• Added a regression test: a project at f:/code/journal with a git root at F:/code/journal now lands in singleGitProjects.

Testing

• npx vitest run src/tests/grouped-projects.test.ts: 18 tests pass.
• Found on Windows 11 with real data: the /projects API response above shows the mismatch for every repo where the session path has a lowercase drive letter.

🤖 Generated with Claude Code

[NicoKiaru]

I checked and with this fix I can see all my sessions for each projects as expected. Thanks for the cool project!

(this message is written by an organic brain)

[JayantDevkar]

Thanks for tracking this down, the f: vs F: explanation matches what I'd expect from Claude Code recording the cwd as typed.

Two things before merging:

1. getRelativePath a few lines down has the same exact-match comparison, so nested projects under one of these roots will now show absolute paths. If you move the normalizer into $lib/utils.ts and use it in both places, both symptoms go away together. Inline notes point at the lines.
2. The comment above normalizePath grew to four lines. We keep code comments to one line in this repo; something like // Normalize separators and uppercase the drive letter so f:/repo matches F:/repo is enough, the rest is already in your PR description.

Longer term the API should probably emit path and git_root_path with consistent casing so the frontend doesn't have to know about drive letters at all, but that's a separate change and not on you.

CI hasn't run on this branch yet (first-contributor approval), I'll kick it off.

[JayantDevkar]

Inline context for reviewers, one note per change area.

[JayantDevkar]

Could this live in $lib/utils.ts as an exported normalizePath and be used by getRelativePath below as well? That function still does a plain startsWith on the un-normalized root, so a nested f:/code/journal/pkg under the new F:/code/journal key renders as an absolute path instead of ./pkg. There are five other .replace(/\\/g, '/') sites across this file and utils.ts, and decodeProjectPath already uppercases the drive on its own.

[JayantDevkar]

Worth adding a nested project to this fixture (path: 'f:/code/journal/pkg', is_nested_project: true) and asserting getRelativePath(...) returns ./pkg. That's the case the current code still misses.