Windows activity paths are dropped when repository casing differs

Summary

Live/saved scan activity path extraction compares repository prefixes case-sensitively even when the path is a Windows drive or UNC path.

On ordinary Windows filesystems, a tool event can refer to the same repository file with different drive/directory casing and Codex Security then reports the activity with an empty paths list.

Reproduction / evidence

Current upstream main at 37bf87a692fc72d41f7312cc48808d699d204fba normalizes backslashes but retains case:

const prefix = `${repository.replaceAll("\\", "/").replace(/\/$/u, "")}/`;
...
const normalized = candidate.replaceAll("\\", "/");
if (normalized.startsWith(prefix)) {
  ...
}

commandRepositoryPaths() uses the same case-sensitive startsWith() for the concrete repository prefix.

The existing test suite already treats Windows paths as valid repository activity inputs, e.g. C:\\code\\juice-shop\\routes\\login.ts against C:\\code\\juice-shop.

A deterministic extension of that case is:

scanActivityFromEvent(
  toolEvent("read_file", {
    path: "c:\\CODE\\JUICE-SHOP\\routes\\login.ts",
  }),
  "C:\\code\\juice-shop",
)

Current behavior: paths: [].

Expected behavior: paths: ["routes/login.ts"].

The same loss occurs for absolute Windows paths embedded in shell commands and for saved-session tool calls, because both flow through the same repository-prefix extraction helpers.

Root cause

Path separators are normalized for Windows-style inputs, but prefix comparison still uses POSIX case-sensitive string semantics. Repository-path style is available from the normalized root itself, so the comparison does not need to depend on the host running the renderer.

Suggested fix

• detect Windows drive/UNC repository roots from their normalized path shape;
• compare only the concrete repository prefix case-insensitively for those roots;
• keep $CODEX_SECURITY_REPOSITORY placeholder matching case-sensitive;
• slice the relative path from the original normalized candidate so display casing is preserved;
• add regressions for tool events, saved-session events, and command extraction.

Impact

This is an observability correctness bug. The scan still reads the file, but live activity and saved-session presentation can omit the affected source path, making Windows scan progress/details incomplete and misleading.

Start with scanActivityFromEvent and commandRepositoryPaths, then trace the saved-session tool-call path through the shared repository-prefix extraction helpers. Run the existing Windows path activity tests and add regressions for differently cased drive or UNC paths in tool events, saved sessions, and commands; done means relative paths are retained while placeholder matching remains case-sensitive.