docs: reference pg_durable.database GUC instead of PGDATABASE env var

[pinodeca]

Summary

Audited references to PGDATABASE (and related env vars) across the repo. The runtime moved to the pg_durable.database GUC a while back, but a few user-facing docs still claimed the background worker reads its target database from POSTGRES_DB/PGDATABASE.

Changes

• USER_GUIDE.md — troubleshooting section now points at the pg_durable.database GUC in postgresql.conf.
• docs/extension_lifecycle.md — two spots in the lifecycle/known-limitations sections corrected to reference the GUC.

Audit notes (no code changes needed)

• Runtime is already GUC-driven: src/lib.rs registers pg_durable.database; src/types.rs::get_database() reads it and defaults to postgres.
• The CREATE EXTENSION database-validation message and the frozen sql/pg_durable--0.1.1.sql install fixture already reference the GUC correctly.
• Shell uses of PGDATABASE in scripts/pg-common.sh, Makefile, scripts/test-upgrade.sh, scripts/test-e2e-local.sh, docs/TESTING.md, and examples/azure-http-domains/scripts/run-test.sh are intentional dev/test ergonomics — they translate the env var into the GUC at cluster-config time.
• docker-compose.yml sets POSTGRES_DB (postgres image convention) and also passes -c pg_durable.database=pg_durable explicitly. Correct.

Other env vars audited at the same time:

• PGHOST — real runtime dependency in src/types.rs for the BGW connection string, defaults to 127.0.0.1. Already documented in docs/security-review/workbook-data.md.
• DUROXIDE_PG_POOL_MAX — internal; the worker sets it from pg_durable.max_duroxide_connections.
• RUST_LOG — documented.
• PGUSER / PGPORT — not used; worker uses the pg_durable.worker_role GUC and PostPortNumber from the postmaster.