In-app PR merge can't authenticate to relay git hosting: git-credential-nostr silently yields no credentials (and needs git ≥ 2.46)

**Environment:** Buzz Desktop AppImage on Pop!_OS 24.04 LTS, system git 2.43.0. Repo hosted on the relay's git hosting (`https:///git//.git`), which requires NIP-98 on **every** request including fetches (anonymous `GET /info/refs` → `401`, `WWW-Authenticate: Nostr realm="buzz"`; Basic auth is rejected).

## Summary

The in-app project-feed **merge always fails on a stock Linux install** when the relay's git hosting requires auth. The merge clones with the system `git`, and the credential plumbing the app sets up never actually produces credentials:

```
Cloning into '/tmp/.tmpXXXXXX/repo'... fatal: could not read Username for
'https:///git//.git': terminal prompts disabled
```

## What we traced

1. **The wiring is present.** Spawned processes get:
```
GIT_CONFIG_COUNT=2
GIT_CONFIG_KEY_0=credential.https:///git.helper
GIT_CONFIG_VALUE_0=$APPDIR/usr/bin/git-credential-nostr
GIT_CONFIG_KEY_1=credential.https:///git.useHttpPath
GIT_CONFIG_VALUE_1=true
```
2. **But the helper has no key.** Its own error strings say it needs `$NOSTR_PRIVATE_KEY` or `git config nostr.keyfile` (0600 keyfile) — neither is provided to the spawned git, so it cannot sign anything.
3. **It fails silently.** `git-credential-nostr get` exits `0` with empty stdout **and empty stderr** in every variant we tried (with/without `NOSTR_PRIVATE_KEY` as nsec or hex, with/without `BUZZ_AUTH_TAG`, with/without `capability[]=authtype` in the request). Git gets nothing, falls back to a terminal prompt, and dies. At minimum the "no nostr key configured" error should reach stderr so the merge surfaces a real diagnosis.
4. **Even fully wired, stock git can't consume it.** The helper's strings show it returns `credential=`/`authtype=`-style output, i.e. the credential-helper *authtype* protocol added in **git 2.46**. Distro git on Ubuntu-noble-based systems is **2.43**, which never advertises `capability[]=authtype` and cannot send `Authorization: Nostr …` from a helper at all. There's no version check or error for this.

Net effect: clone 401s → merge fails, with a misleading "could not read Username" error.

## Suggestions

- Pass the key material to the spawned git (e.g. a 0600 keyfile + `GIT_CONFIG` entry for `nostr.keyfile`), or perform the merge's git transport with credentials the app controls.
- Make `git-credential-nostr` fail loudly on stderr when it can't produce credentials.
- Check/document the minimum git version (≥ 2.46 for authtype helpers), or bundle a suitable git.
- Alternative that works on any git version: the relay (as observed) doesn't strictly bind the NIP-98 `method` tag per request, so a one-shot token via `-c http.extraheader=Authorization: Nostr ` per git invocation is sufficient for a whole clone/fetch/push.

## Workaround we're using

A PATH-first `git` wrapper that detects the relay's git host, signs a fresh NIP-98 token (kind 27235, `u` = repo base `.git` URL + owner-attestation tag), and injects it via `http.extraheader`. With that in place the in-app merge completes end-to-end (clone → merge → push).

Related: #2315 (the AppImage env leak also crashed the merge's `git-remote-https` before we got this far).