buzz-db: shared test infrastructure (scratch DB, community seeding)

[TheSentinel454]

Every test module that needs Postgres repeats the same boilerplate: PgPool::connect, create_scratch_db, make_community, insert_user, cleanup. There is no shared test utility module. A #[cfg(test)] test-utils submodule with common helpers would reduce duplication and make writing new integration tests easier. Priority: Low — developer productivity improvement.

🤖 AI review update (2026-08-23)

Clarify who must consume the helpers. A plain cfg(test) module works only inside buzz-db; cross-crate and integration tests need tests/common, a dev-only support crate, or a feature-gated support module. Prefer sqlx::test where it fits, unique per-test databases/schemas, deterministic seed builders, and cleanup guards safe under parallel execution.

[TheSentinel454]

🤖 Follow-up from block#6660: add a dedicated PostgreSQL test lane once the shared test infrastructure in this issue exists.

The block#6660 proving slice adds a deliberately focused selector for its four new buzz-db persistence tests. That closes the immediate concurrency/rollback/mention-atomicity coverage gap, but it should not become the long-term pattern. The dedicated lane should automatically include all tests classified as PostgreSQL-backed so new DB tests are picked up without editing an exact test-name selector.

Suggested scope / acceptance criteria:

• Define one discoverable convention for PostgreSQL-backed tests across crates (rather than relying on ad hoc #[ignore] plus hand-maintained names).
• Run that complete set in a separate CI lane with PostgreSQL available and parallel-safe, per-test database/schema isolation.
• Share scratch DB creation, migration/schema bootstrap, deterministic community/user seeding, and cleanup guards across buzz-db, relay unit tests, and integration tests.
• Document whether a test expects migration-applied state or the desired-state schema/schema.sql contract; exercise both intentionally where parity matters.
• Ensure destructive migration tests cannot reset a database used concurrently by other tests.
• Keep infrastructure-free unit jobs fast and independent from PostgreSQL.

Concrete blockers exposed by block#6660 validation:

• A legacy migration test resets the shared public schema and races other ignored PostgreSQL tests.
• Relay workflow persistence tests try to run migrations on CI's already-applied desired-state database and fail with type "channel_type" already exists.
• NIP-RS/mesh trigger tests pass on a migration-applied database but currently expose drift when run against CI's desired-state schema.

Reference: block#6660