Native git repository is unavailable after a volume-level isolated restore

[C0dino]

Summary

A channel-bound NIP-34 repository accepts a signed push and clone in production, but the same authenticated clone returns repository not found after an isolated restore even though the repository announcement and object-store pointer are present.

Reproduction

1. Create a channel-bound NIP-34 repository and push one empty commit with git-credential-nostr.
2. Verify two authorized members clone the same SHA and a non-member receives HTTP 403.
3. Quiesce the write path and archive Postgres, Redis, MinIO, and git scratch volumes with checksums.
4. Restore all volumes into an isolated stack using the same community host mapping and storage credentials.
5. Verify relay liveness, community/member counts, the kind 30617 announcement, and the MinIO repository pointer.
6. Attempt an authenticated clone against the isolated relay using a host-bound NIP-98 token.

Expected

The restored relay advertises and clones the same repository SHA.

Actual

The clone returns repository not found. The restored database contains the kind 30617 announcement, the restored MinIO volume contains the community/owner/repository pointer, and the relay git object-store conformance probe reports success.

Environment

• buzz: desktop-v0.5.3 server source
• database: Postgres 17
• cache: Redis 7
• objectStore: MinIO path-style S3
• gitClient: Git 2.46.3 with git-credential-nostr

Impact

A generic full-stack restore can report healthy while native repository recovery is still incomplete, so self-hosters need a repository-level readback gate before treating a backup as recoverable.

Workaround

Keep critical repositories on an external forge and add an authenticated clone/readback to restore drills.

Disclosure check

• Client data: no
• Credentials or private hosts: no
• Reproduction uses a noncritical empty-commit repository