Attested main relay image omits migrations 0029-0032

### Summary

The official attested `ghcr.io/block/buzz:sha-8c0f42e` image does not appear to embed migrations 0029-0032 even though its OCI revision and GitHub attestation bind it to `8c0f42e187ca82d701251fc849217530178ebace`, whose tree contains those files.

Image manifest digest: `sha256:de7b7585db46928bc3ea017de7906004f93c2df3e26978064081b9b8b894ac6f`.

### Reproduction

1. Start a disposable PostgreSQL instance with a database migrated through 0026.
2. Run this image's `buzz-admin migrate` against it.
3. The command exits 0 and prints `Database migrations complete.`
4. Query:

```sql
select max(version), count(*) from _sqlx_migrations;
select version, description from _sqlx_migrations where version >= 27 order by version;
```

Observed:

```text
28|28
27|channels id lookup index
28|long reaction payloads
```

The source tree at the attested revision contains `migrations/0029_community_deletion.sql` through `migrations/0032_channel_roster_snapshot_fence.sql`, and `crates/buzz-db/src/migration.rs` uses `sqlx::migrate!("../../migrations")`.

### Impact

An operator can receive a successful migration result from this exact-main image while remaining four migrations behind its source tree. This makes the image unsafe to promote as a schema gate.

A likely area to inspect is Docker/Cargo caching and whether migration-only changes invalidate the `buzz-db` compilation that embeds `sqlx::migrate!` assets.

Run the disposable PostgreSQL reproduction with the attested image, then inspect crates/buzz-db/src/migration.rs and migrations/0029_community_deletion.sql through migrations/0032_channel_roster_snapshot_fence.sql. Check Docker/Cargo caching and whether migration-only changes invalidate the sqlx::migrate!("../../migrations") assets; done means the exact image applies migrations 0029-0032 and reports the expected latest version.

Written by the indexing model from the issue text.