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

### 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\--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\--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\--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.
3. The same direct clone using an explicitly constructed `\\?\` destination failed with the same Invalid argument error before authentication or checkout.
4. `git init --bare` with an explicit `\\?\` destination also failed with `Invalid argument`.
5. 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.longpath`s 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 `.
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