[albatrossflyon-coder]

Closes #2919.

Root cause (more precise than the original title)

Not actually a case-sensitivity issue — Claude Code replaces : with
- along with /, ., _, \, and non-ASCII characters when it
slugs a project's cwd into its session folder name under
~/.claude/projects/. encode_project_path's SANITIZED_CHARS never
included :, so on Windows the filter string kept a literal colon
right after the drive letter while the real on-disk folder name never
had one.

Verified against several of my own real ~/.claude/projects/ folders
before writing the fix:

Real cwd	Real folder on disk
C:\Repos\job-hunter	C--Repos-job-hunter
G:\Other computers\...\Universal-Brain	G--Other-computers-...-Universal-Brain

So the default (no -p, no --all) filter was comparing
"C:-Users-..." against the real "C--Users-..." — never matches,
hence Scanned: 0 sessions, while --all/-p <name> (which don't
go through this exact comparison) work fine, matching the report.

Fix

Added : to SANITIZED_CHARS. The existing
test_encode_project_path_windows test was actually asserting the
buggy output ("C:-Users-foo-bar") — corrected it, and added an
end-to-end regression test exercising the full
discover_sessions_in_projects_dir match path.

Before / after, live on this machine

$ rtk discover   # before
Scanned: 0 sessions (last 30 days), 0 Bash commands

$ rtk discover   # after, same repo, no other changes
Scanned: 30 sessions (last 30 days), 4575 Bash commands

Tests

cargo test --bin rtk: 2434 passed, 9 ignored (pre-existing Windows
.exe-extension limitation on the #[ignore]d real-binary tests
elsewhere in this repo, covered by CI on Linux/macOS — unrelated to
this change). cargo fmt --check and cargo clippy --all-targets:
both clean.

Note on the space-in-username report

The issue thread also mentions a separate symptom with a space in the
Windows username (C:\Users\Jeff Huang\...). Spaces were already in
SANITIZED_CHARS before this fix and I couldn't reproduce a
space-specific failure on this machine (no space in my own username),
so I'm not claiming this PR resolves that report too — flagging it in
case it needs separate follow-up.

[albatrossflyon-coder]

This looks superseded, closing rather than merging. f496f59 (2026-08-15, part of the decode/exec_capture refactor addressing #2717) already fixed encode_project_path to sanitize the drive-letter colon, same underlying bug this PR targets (same test assertion, same result). This PR predates that fix (opened 2026-07-17) and now conflicts with it. No action needed on the newer code, it already handles the Windows drive-letter case.