desktop: Projects repo browser fails with generic 'Repository unavailable' when resolved git is <2.46 (git-credential-nostr authtype requirement)

## Summary

The desktop Projects repo browser shows a generic **"Repository unavailable — Buzz could not load this repository"** error when the resolved `git` binary is older than 2.46, because `git-credential-nostr` requires the credential-protocol `authtype` capability (git 2.46+). On a stock macOS setup this is the *default* outcome: GUI apps don't inherit the user's shell PATH, so the app resolves `/usr/bin/git` (Apple git 2.39) even when a modern Homebrew git is installed at `/opt/homebrew/bin/git`.

## Repro

1. macOS with Homebrew git ≥2.46 installed, but launch Buzz.app from Finder/Dock (GUI PATH = `/usr/bin:/bin:...`, no Homebrew).
2. Open a Project backed by a relay-hosted (NIP-98 authed) repo.
3. Repo browser fails with "Repository unavailable". Retry does not help.

## Root cause

- `build_git_auth_config_for_keys` (`desktop/src-tauri/src/commands/project_git_exec.rs`) resolves `git` via `resolve_command` (`desktop/src-tauri/src/managed_agents/discovery.rs`). Plain PATH lookup wins before `common_binary_paths()` is consulted, so `/usr/bin/git` 2.39 shadows Homebrew git even though `/opt/homebrew/bin` is in the fallback list.
- With git <2.46 the credential protocol never advertises `capability[]=authtype`, and `git-credential-nostr` intentionally exits silently in that case (`crates/git-credential-nostr/src/lib.rs:160`), per its documented git 2.46+ requirement.
- git then fails with `fatal: could not read Username for 'https://…': Device not configured` against the relay's 401.
- `projectRepoUnavailableReason` (`desktop/src/features/projects/lib/projectRepoAvailability.ts`) doesn't match that message, so it falls through to `unknown` → the unhelpful "Repository unavailable / contact the project owner" panel.

Verified both directions on the same machine against the same relay repo:
- `/opt/homebrew/bin/git` (2.55) + bundled helper → clone succeeds
- `/usr/bin/git` (2.39.5, Apple Git-154) + bundled helper → `could not read Username … Device not configured`

## Suggested fixes (any subset)

1. **Version-aware resolution:** when resolving `git` for credential-authed operations, prefer a candidate with version ≥2.46 (check `git --version` across PATH + `common_binary_paths()`), instead of first-hit-wins.
2. **Actionable error:** detect `could not read Username` / git <2.46 in the snapshot command and return a typed error so the UI can say "Buzz needs git 2.46 or newer for authenticated repos — found 2.39 at /usr/bin/git" instead of "Repository unavailable".
3. **Availability mapping:** add `could not read username` to the `authentication` regex in `projectRepoAvailability.ts` so it at least lands on the auth-flavored message rather than `unknown`.

## Workaround

`launchctl setenv PATH "/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"` and relaunch Buzz (doesn't survive reboot).

## Environment

- Buzz Desktop 0.5.8, macOS (Darwin 25.5), Apple git 2.39.5 at `/usr/bin/git`, Homebrew git 2.55 at `/opt/homebrew/bin/git`
- Relay-hosted NIP-34 repo requiring NIP-98 auth for clone

Start with build_git_auth_config_for_keys in desktop/src-tauri/src/commands/project_git_exec.rs and resolve_command in desktop/src-tauri/src/managed_agents/discovery.rs, then inspect the credential helper behavior at crates/git-credential-nostr/src/lib.rs:160. Review projectRepoUnavailableReason in desktop/src/features/projects/lib/projectRepoAvailability.ts and reproduce with the Git versions described. Done means authenticated repository browsing no longer produces the generic unavailable result when an older Git is resolved.

Written by the indexing model from the issue text.