[Bug] Windows Projects clone passes a \?\ extended path to Git and fails with Invalid argument

[Murcho]

Summary

On Windows, Buzz Desktop Projects cannot clone a repository because the destination passed to git clone begins with the Windows extended-length path prefix (\?). Git for Windows rejects that destination before authentication or checkout:

fatal: could not create work tree dir '\\?\C:\Users\james\.buzz\REPOS\<owner>--gamepad-bridge': Invalid argument

The same repository clones successfully on the same machine when Git receives an ordinary absolute Windows path.

Environment

• OS: Windows
• Buzz Desktop: 0.5.2
• Git for Windows: 2.55.0.windows.3
• Relay: Self Hosted Relay server : ghcr.io/block/buzz:main : sha256:36b19eb85b10c09ecef36b24d788c6b54bb62fdfde36e598d3ce88f21fb85dbb
• Repository: gamepad-bridge
• Nostr credential helper: git-credential-nostr (installed and working)

Steps to reproduce

1. On Windows, open the repository in Buzz Desktop Projects.
2. Choose the action that clones/fetches the repository locally.
3. Observe the clone failure.

Actual result

Desktop invokes Git with a clone destination in this form:

\\?\C:\Users\james\.buzz\REPOS\<owner>--gamepad-bridge

Git exits with status 128 and reports Invalid argument while creating the work tree directory.

Expected result

Desktop should pass Git an ordinary fully-qualified destination such as:

C:\Users\james\.buzz\REPOS\<owner>--gamepad-bridge

The project should clone successfully, with Git managing any internal long-path conversion itself.

Control tests

These tests were run on the affected machine:

1. A direct Nostr-authenticated git clone of the same relay repository to a normal absolute destination succeeded.
   • This proves the repository, relay access, Nostr key, git-credential-nostr, and normal local checkout all work.
2. The same direct clone using an explicitly constructed \\?\ destination failed with the same Invalid argument error before authentication or checkout.
3. git init --bare with an explicit \\?\ destination also failed with Invalid argument.
4. The explicit-prefix test fails with both settings:

core.longpaths=true  -> fatal: cannot mkdir \\?\C:\...: Invalid argument
core.longpaths=false -> fatal: cannot mkdir \\?\C:\...: Invalid argument

Therefore changing core.longpaths does not make Git accept a caller-supplied extended-path destination.

Likely cause

The relevant Desktop code canonicalizes the REPOS root, appends the repository name, then passes that string directly as the final git clone argument:

• desktop/src-tauri/src/commands/project_repo_paths.rs: canonicalize_repos_root() calls PathBuf::canonicalize().
• desktop/src-tauri/src/commands/project_git_workflow.rs: clone_project_repository_blocking() appends the repository name and passes repo_dir.to_str() to git clone --end-of-options <url> <destination>.
  On Windows, std::fs::canonicalize() returns an extended-length path. That implementation detail leaks into the external Git CLI argument.

Proposed fix

At the Windows Git-command boundary, convert a canonical extended-length destination back to an ordinary fully-qualified path before passing it to git clone. The canonical form can still be retained for path containment/security checks. Let Git for Windows apply its own long-path handling internally when needed.

Please add a Windows regression test that verifies the spawned clone command receives a normal absolute destination, not one starting with \\?\.

References

Git for Windows documents core.longpaths as Git's internal long-path handling: https://gitforwindows.org/git-cannot-create-a-file-or-directory-with-a-long-path.html
Microsoft documentation for extended-length paths: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

Related issues

These look related to Windows Projects/Git integration but are not duplicates of the destination-path failure:

#3025
#3298
#3462