CI architecture: clone isolated lane databases from one migrated PostgreSQL template

[Konan69]

Context

PR #180 introduces four semantic backend test lanes. The three PostgreSQL lanes share one server but currently run Alembic independently in separate databases. The next infrastructure step is to migrate one immutable template database once, then clone isolated lane databases from it.

Outcome

Reduce PostgreSQL lane startup cost without sharing mutable state or weakening production-parity database proof.

Scope

• Test runners, fixtures, CI, and test documentation only.
• Create one coordinator-owned template database at Alembic head.
• Clone one database and create one role per PostgreSQL lane.
• Keep lane URLs, settings caches, coverage files, and temporary directories isolated.
• Preserve real PostgreSQL behavior for triggers, locks, constraints, transactions, concurrency, and asyncpg.
• Clean up template, lane databases, and roles after success, failure, timeout, or interruption.

Acceptance criteria

• Alembic runs once per CI job before lane cloning.
• No active connection exists when PostgreSQL clones the template.
• Every lane owns a distinct database and role with least-required privileges.
• The clone preserves schema, triggers, constraints, and the exact Alembic head.
• Mutable state cannot cross lane boundaries.
• Cleanup is fail-closed and covered for success, failure, timeout, and signals.
• Existing global and protected coverage floors remain unchanged.
• A benchmark demonstrates a measurable improvement over PR Cut backend CI runtime 66%: 16m → 5m with isolated semantic test lanes #180's topology.

Non-goals

• PGlite substitution.
• Production migration changes.
• Application architecture changes.
• Arbitrary weighted sharding or cross-job database sharing.