git-credential-nostr silently ignores BUZZ_PRIVATE_KEY — its env override is NOSTR_PRIVATE_KEY, unlike other components

**Describe the bug**

Most identity-consuming components use `BUZZ_PRIVATE_KEY` (`buzz-cli` declares it as a required arg env at `crates/buzz-cli/src/lib.rs:85`; the ACP/MCP shim passes it to shell children; buzz-admin reads it). The git credential helper alone resolves identity from `NOSTR_PRIVATE_KEY` (`crates/git-credential-nostr/src/lib.rs:51`, `load_key()`), falling back to `git config nostr.keyfile`.

A user who exports the ecosystem-standard `BUZZ_PRIVATE_KEY` gets no error and no warning: the helper silently signs as the key file's identity instead, and the resulting server rejection (`pre-receive hook declined`) is indistinguishable from a permissions problem with the intended identity.

**Steps to reproduce**

1. Configure `git config nostr.keyfile` with identity A (a channel member).
2. `export BUZZ_PRIVATE_KEY=` where B is the repo owner.
3. Run an owner-gated operation, e.g. `git push :refs/heads/some-branch`.
4. The push is rejected exactly as it would be for identity A — the env var was never consulted.

**Expected behavior**

In order of preference (deferring to maintainers on direction):

1. The helper warns on stderr when `BUZZ_PRIVATE_KEY` is set but unused — pure DX improvement, no new security surface, and it breaks the silent wrong-identity trap.
2. The naming difference is documented where the helper is introduced.
3. Optionally, the helper also accepts `BUZZ_PRIVATE_KEY` (keeping `NOSTR_PRIVATE_KEY` for back-compat) — noting #3478 moved toward keyfile handoff for env-borne keys, so an env alias may be against the intended direction; happy to follow whichever pattern is preferred.

I am glad to submit a PR for the chosen direction (DCO sign-off and Conventional Commits understood).

**Version and platform**

- Buzz version: 0.5.3 (behavior also present at current `main` — `crates/git-credential-nostr/src/lib.rs:51`)
- OS: macOS 15

**Logs / additional context**

Hit while performing an owner-signed ref deletion on a relay-hosted repo: the silent fallback cost a debugging round and a key-file-swap workaround before a source read revealed the variable-name difference. Prior-art searched across open/closed issues and PRs (`NOSTR_PRIVATE_KEY`, `BUZZ_PRIVATE_KEY`, `git-credential-nostr`, credential-helper env synonyms) — closest matches #2316 (silent no-credentials on old git) and #3478 (keyfile migration) do not cover this.