Remote project folder binding fails when stored paths contain doubled separators

Problem

Managed remote-project paths can be persisted with doubled path separators, for example:

/Users/me/org//some-project
C:\Users\me\org\\some-project

Remote still shows the chat, but project folder binding fails because the stored path does not match the real directory (.../org/some-project).

This can happen when an org/workspace prefix that already ends with a separator is joined to a project name that already starts with one.

Expected

• Normalize stored project paths (project_roots.path) and thread working directories (threads.cwd) on write by collapsing redundant / and \\.
• Preserve a leading UNC/network prefix (// or \\\\).
• Backfill existing bad rows so already-created remote projects bind again.

Actual

Doubled separators are stored as-is. Remote can list the thread, but folder binding/lookup against the real path fails.

Suggested fix

Rewrite // (and equivalent mixed / \\ runs) at the SQLite write boundary, and add a migration that normalizes existing project_roots.path and threads.cwd values.

Proposed implementation: RaviTharuma/codex branch cursor/normalize-remote-path-slashes-78bc (compare against openai/codex).

Supersedes #43242 (created with an incomplete body due to a token permission limit on issue updates).

Start at the SQLite write boundary and inspect how project_roots.path and threads.cwd are stored. Compare the proposed cursor/normalize-remote-path-slashes-78bc branch with openai/codex, then add the migration that backfills existing rows. Done means redundant separators are normalized while leading UNC prefixes remain intact and remote folder binding works again.