Fresh `deploy/compose` stack: relay crash-loops on `/data/git/.pack-cache` (root-owned named volume vs non-root uid 1000)

## Summary

A first-run of the production Compose bundle in `deploy/compose/` never reaches a healthy relay. The `buzz-git-data` named volume is created root-owned, but the relay container runs as non-root (`buzz:buzz`, uid 1000, per `Dockerfile:153`), so `BUZZ_GIT_PACK_CACHE_PATH` cannot be created and the container restart-loops.

## Environment

- Relay image: `ghcr.io/block/buzz:main` (digest-pinned), Linux x86_64 VPS
- Docker 29.4.1, Compose v5.1.3
- `deploy/compose/compose.yml` + a small local override (port binding + memory limits only; no changes to volumes or user)
- Fresh host, no pre-existing volumes

## Steps to reproduce

1. Copy `deploy/compose/`, fill `.env` from `.env.example` (all `CHANGE_ME` replaced)
2. `docker compose up -d`
3. `docker compose ps` / `docker compose logs relay`

## Actual

Postgres, Redis and MinIO go healthy; the relay never does:

```
ERROR Invalid configuration: invalid config: BUZZ_GIT_PACK_CACHE_PATH=/data/git/.pack-cache could not be created: Permission denied (os error 13)
Error: Configuration error: invalid config: BUZZ_GIT_PACK_CACHE_PATH=/data/git/.pack-cache could not be created: Permission denied (os error 13)
```

repeating on the restart policy indefinitely. `/_readiness` is unreachable for the entire time.

## Expected

Either the relay creates its own cache directory inside the volume it was given, or the bundle prepares ownership so the non-root runtime user can.

## Workaround (confirmed)

```
docker compose down
chown -R 1000:1000 "$(docker volume inspect _buzz-git-data --format '{{.Mountpoint}}')"
docker compose up -d
```

Relay then starts cleanly, passes the A3 git object-store conformance probe, and `/_readiness` returns 200.

## Suggested fix

Any of: an init step in the bundle that chowns the volume (the pattern already used for `minio-init`), a `user:` / entrypoint chown in the relay service, or — cheapest — a documented prerequisite in `deploy/compose/README.md`. Happy to send a PR for whichever you prefer.

## Notes

Not reproducible with the root-level `docker-compose.yml` dev stack, which is presumably why it survives: the failure is specific to the production bundle on a clean host.