fix(discover): sanitize drive-letter colon so Windows discover finds sessions

[zbl1998-sdjn]

Problem

On Windows, the default rtk discover (current-project mode) always reports Scanned: 0 sessions. --all and -p PROJECT work, so history parsing is fine — only current-project resolution fails. (#2919)

Root cause

ClaudeProvider::encode_project_path mirrors Claude Code's cwd → ~/.claude/projects/ slug encoding, replacing separators with -. Its SANITIZED_CHARS list ('/', '.', '_', '\\', ' ', '[', ']') is missing the drive-letter colon :.

Every Windows cwd carries one, so:

C:\Users\me\proj   -> rtk encodes    "C:-Users-me-proj"
C:\Users\me\proj   -> Claude folder  "C--Users-me-proj"   (Claude replaces ':' too)

The C:- vs C-- mismatch means the encoded slug is never a substring of the real folder name, so the substring match in discover_sessions_in_projects_dir finds nothing → 0 sessions. This also lines up with @superjaff's note above that Claude's sanitizer maps : \ / and spaces to -.

Ground truth on a Windows box: C:\Users\Administrator lands in ~/.claude/projects/C--Users-Administrator — Claude replaces the colon with -.

Fix

Add ':' to SANITIZED_CHARS (one char). The encoder is shared, so this also fixes the same 0-sessions symptom in rtk learn.

Tests (TDD, red → green)

• test_encode_project_path_windows — corrected expectation: C:\Users\foo\bar → C--Users-foo-bar (was C:-Users-foo-bar, which had encoded the bug).
• test_encode_project_path_windows_full_path — regression for a full Windows cwd.

Verified on Windows (rustc 1.96.0)

• cargo fmt --all -- --check — clean
• cargo clippy --all-targets -- -D warnings — zero warnings
• cargo test discover::provider::tests — 21/21 pass
• End-to-end from a real project dir:
  • before: Scanned: 0 sessions
  • after: Scanned: 1 sessions

(A full cargo test --all on my local Windows box has 16 pre-existing core::stream failures that spawn cat/echo, absent from my PATH — the identical 16 fail on unmodified develop, and they pass on CI's windows-latest.)

Scope

Colon sanitization is the deterministic root cause that breaks every Windows path. Drive-letter case-insensitivity (an uppercase E: cwd vs a lowercase e-- folder created by a different launch) is a separate, situational concern, left out of this focused PR.

Closes #2919

[CLAassistant]

All committers have signed the CLA.

[Copilot]

Pull request overview

Fixes Windows-only current-project discovery by aligning ClaudeProvider::encode_project_path with Claude Code’s project-folder slug sanitization (drive-letter : → -), so rtk discover (and shared users like rtk learn) can find sessions under ~/.claude/projects/.

Changes:

• Add : to the SANITIZED_CHARS list used by encode_project_path, preventing C:-... vs C--... mismatches on Windows.
• Update the Rustdoc examples/comments to reflect the corrected Windows encoding output.
• Update/extend unit tests to assert the corrected Windows slug and add a full-path regression case.

[zbl1998-sdjn]

A correction to my own description above, now that I've had the chance to pin it down.

I wrote that a full cargo test --all on my Windows box had 16 pre-existing core::stream failures. That was true, but I misattributed the cause — it's just PATH. Those tests spawn cat and echo; run the suite from PowerShell, where neither is on PATH, and exactly those 16 fail (2440 passed / 16 failed). Run it from Git Bash, where both resolve, and the whole suite is green (2467 passed / 0 failed / 8 ignored). Same commit either way, so the caveat in the description doesn't really apply and this branch is clean on a full run. Sorry for the noise.

Something I should have checked before opening this, and have now: instead of inferring the encoding from folder names, I read the slug function in the installed Claude Code binary (2.1.215). It replaces every non-alphanumeric character with -, then truncates at 200 characters and appends a hash of the original path. That's good news for this PR — it means the colon is replaced on every platform, not just Windows, so adding ':' can't regress a Unix path that happens to contain one.

It also means SANITIZED_CHARS will keep drifting from that rule. (, ), +, &, @, , and friends still aren't replaced, and the 200-character cap isn't mirrored, so those paths still find zero sessions on any platform. I've kept this PR to the one character that breaks every Windows path, since that's the deterministic root cause, but if you'd prefer the encoder to mirror the rule directly I'm happy to open a follow-up for it.

Thanks for your time, and no rush from my side.

[KuSh]

LGTM!

Could you remove the duplicated test as it doesn't add anything except more maintenance surface. Thanks