Support pg_durable installations across multiple databases

[Pino de Candia (pinodeca)]

Summary

Allow CREATE EXTENSION pg_durable in satellite databases while keeping one shared Duroxide runtime/provider in the explicitly installed control database (pg_durable.database).

• Keep metadata, RLS, variables, HTTP permissions, and caller transaction behavior local to the originating database. Default SQL execution to that database; preserve explicit SQL targets.
• Namespace internal satellite instance IDs by database OID and installation UUID while preserving public eight-character IDs and existing recorded orchestration payloads.
• Route activity and backend API access to the correct origin/control database, with bounded connection budgets, query deadlines, and fresh installation checks.
• Fence drop/recreate races, including SQL queued before a forced database replacement. Add bounded retention and conservative removed-origin reconciliation.
• Document installation, privileges, operational behavior, and migration compatibility. Keep docs/multi-database-installation.md as the design/decision record; USER_GUIDE.md and docs/multi-database.md provide user-facing guidance.

Operational Semantics

Install and initialize the control extension first, then install satellites. Preloading alone does not create provider objects. Dropping a satellite affects its own work; dropping the control extension destroys shared engine state for all satellites. There is no cross-database reference count or permanent drop veto.

pg_durable.max_origin_connections is a new restart-time shared origin connection budget (default 12). Independent new-transaction start admission remains per database.

Upgrade & Migration

• Add installation identity DDL to fresh 0.2.8 installs and the 0.2.7-to-0.2.8 upgrade script.
• Preserve legacy control schemas and unprefixed control instance IDs. Provider migrations remain background-worker-owned.
• Validate current satellites alongside every supported older control schema (0.2.2 through 0.2.7) without requiring ALTER EXTENSION UPDATE on the control.

Validation

Local validation completed on commit 86e039f5d62badaf058d682fda012a4ea0a33527:

• Full E2E suite: 62 passed, 0 failed, including lifecycle, reconciliation, guard and forced-replacement cases (72–75), plus HTTP feature variants.
• Full pgrx unit suite: 362 passed, 0 failed, 16 ignored.
• All 115 upgrade checks passed, including six simultaneous current-satellite/legacy-control cases.
• cargo build --features pg17 passed.
• cargo clippy --features pg17 -- -D warnings passed.
• Formatting, staged/diff whitespace checks, and 33 relative documentation file links passed.
• Four existing boolean-assertion warnings in pgrx tests are unchanged from main. High-origin-count load and performance benchmarks were not run.

These are local results; GitHub CI and colleague review are separate gates.

Try It

Use a disposable local PostgreSQL test environment. The repository scripts install the extension and restart the local test server.

git fetch origin
git switch feat/multi-database-installation
./scripts/test-e2e-local.sh 14_database --verbose
./scripts/test-e2e-local.sh multi_database --verbose

For manual setup, follow Multi-Database Support. Useful review scenarios include two satellite roles with isolated metadata, an explicit third SQL target, drop/recreate while work is waiting, and control outage/recovery.

Local agent review artifacts in .context/ and the unrelated duroxide-pg-opt/ checkout are not part of this PR.