Git: accepted repository announcement remains unavailable after same-owner repair

## Summary

A channel-bound NIP-34 repository announcement is accepted and can be read back from the relay, but authenticated Git Smart HTTP still returns `404 repository not found`. Re-announcing the repository as the same owner does not repair access.

This is distinct from #3539: the current CLI writes the `buzz-channel` binding, and the binding is present and valid in this reproduction.

## Environment

- Relay-reported version: `0.2.0`
- Buzz Desktop and bundled CLI: `0.5.5`
- Git: `2.53.0.windows.2`
- Hosted multi-community relay
- Repository owner is a current member of the bound channel

The relay hostname and identifiers are omitted from this public report, but can be supplied privately if useful.

## Reproduction

1. Create a repository with `buzz repos create ... --channel `.
2. Read back the kind `30617` announcement and verify:
- the clone URL is correct;
- the `buzz-channel` tag is present;
- the owner is a member of that channel.
3. Attempt `git ls-remote `.
4. Re-run `buzz repos create` for the same repository ID and same owner.
5. Confirm the replacement announcement is accepted.
6. Retry authenticated `git ls-remote`.

## Observed

The redacted Git trace is consistently:

```text
GET /info/refs?service=git-upload-pack
HTTP 401
WWW-Authenticate: Nostr ...
git-credential-nostr get
GET /info/refs?service=git-upload-pack
Authorization: Nostr
HTTP 404
repository not found
```

The `401` challenge, credential-helper invocation, and signed retry show that NIP-98 authentication is working. Three authenticated retries after the accepted same-owner re-announcement still returned `404 repository not found`.

The same behavior was reproduced with a second, independently announced repository.

## Expected

On a new announcement, the relay should seed the empty manifest pointer and make the repository available for its initial push. If that pointer is absent, a same-owner re-announcement should repair it.

If the side effect or object-store write fails, repository creation should fail visibly or expose a diagnosable failure state rather than reporting only that the Nostr event was accepted.

## Source-level context

In the official `relay-v0.2.0` source at commit `0d9be2fde1fc18e57da8f2ca229cc01699867550`:

- `handle_repo_announcement` seeds repository state;
- `ensure_manifest_pointer` is intended to repair an absent pointer on a same-owner re-announcement;
- `seed_manifest_pointer` creates the initial empty pointer;
- Git `info/refs` returns `404 repository not found` when the manifest pointer cannot be loaded.

The live evidence suggests either:

1. the announcement side effect is not completing;
2. the Git object-store pointer cannot be written or read; or
3. the event is acknowledged even when the required side effect fails.

## Suggested improvements

- Log and surface failures from repository-announcement side effects with the repository ID and event ID.
- Do not present repository creation as successful when manifest-pointer seeding fails.
- Add an operator health or repair command that verifies the announcement, channel binding, manifest pointer, initial ref state, and authenticated `info/refs` end to end.
- Add a regression test where the first manifest-pointer write fails, followed by a same-owner re-announcement.

Happy to provide the redacted trace and exact relay/event identifiers privately.