Commits panel can't resolve contributor avatar without prior PR/issue participation

## Summary

Repository announcements (kind `30617`) have no way to add contributor pubkeys directly. Today the *only* way a pubkey enters a project's contributor/profile-lookup set (`desktop/src/features/projects/ui/useProjectDetailPeople.ts`) is:

- being the repo `owner`,
- being in `repository.contributors` (sourced from signed `p` tags on the `30617` event, or `auth` tags added automatically on clone/push), or
- authoring/commenting/reviewing a PR or issue on that repo.

Plain `git` commit authorship is *not* one of those paths, even though the commits panel visually attempts to resolve a Nostr profile (avatar, display name) for each commit author via `profileForCommitAuthor` (`desktop/src/features/projects/lib/projectContributorMatching.ts:151`).

## Observed symptom

A contributor who has pushed real commits (matching git author name/email to their Nostr profile's `displayName`) but has never opened/commented on a PR or issue, and was never added as a `p` tag on the repo announcement, shows up in the commits panel with a generic initials/letter avatar — even though their `kind:0` profile has a correct, publicly-loadable `picture` URL. This looks exactly like a caching or CORS/CSP bug, and is easy to misdiagnose as one, because:

- the profile's `picture` field on the relay is correct,
- the image URL itself loads fine (200, correct content-type, no CSP block), and
- the matching heuristic (`profileForCommitAuthor`) is implemented correctly.

The actual break is upstream: `useUsersBatchQuery` is only ever called with `peoplePubkeys` built from `projectPeople(repository)` (owner + `repository.contributors`) plus PR/issue participant pubkeys (`useProjectDetailPeople.ts`). If a contributor's pubkey was never added through one of those signed paths, it's never fetched, so `profileForCommitAuthor`'s search (`Object.entries(profiles)`) has nothing to match against, regardless of how correct their raw profile data is.

## Repro

1. Announce a repo (`buzz repos create ...`) as user A.
2. Have user B push a commit with `git config user.name`/`user.email` matching their Nostr profile's `displayName`, but have B never open/comment on a PR or issue on that repo, and never get added as a `p` tag on the repo announcement.
3. Set a valid `picture` URL on B's `kind:0` profile.
4. Open the project's commits panel. B's commit shows a fallback/initials avatar, not the real one, regardless of relaunching the app or how long it's been.
5. Have B open (or comment on) any issue/PR in the project. Their pubkey now enters `peoplePubkeys`, gets batch-fetched, and the same commit immediately resolves the correct avatar — no other change needed.

## Suggested fix

One or both of:

- Add a way to add contributor pubkeys directly to a repo announcement (e.g. a `--contributor ` flag on `buzz repos create` that emits additional `p` tags), so contributors don't need to create PR/issue noise just to become visible, or
- Have the commits/contributors panels widen their profile fetch to include the git-author-matched pubkeys they can already resolve locally (e.g. via a name/email → pubkey search), instead of requiring the pubkey to already be in the PR/issue/`p`-tag set before it can look itself up.

Happy to provide more repro detail if useful — found this while debugging why a teammate's avatar wasn't showing up in a project's commits panel.

Start with desktop/src/features/projects/ui/useProjectDetailPeople.ts and desktop/src/features/projects/lib/projectContributorMatching.ts:151, then trace how peoplePubkeys reaches useUsersBatchQuery. Reproduce the listed commit-author scenario and confirm that a contributor without prior PR/issue participation can have their profile fetched and their avatar resolved without relying on unrelated participation.

Written by the indexing model from the issue text.