Performance baseline and Postgres settings for small servers

Steps 1 and 2 of #798, pulled into 4.2.0 so the first configured site (rckoronadal.org, #722) starts on a tuned 2 GB VM with numbers to compare against.

## 1. Baseline

- Enable `pg_stat_statements` in `docker-compose.prod.yml` and `quickstart/` (`shared_preload_libraries` plus `CREATE EXTENSION` on first start), so slow queries can be found.
- Add a repeatable load script for public delivery: the list, an entry by slug, and `GET /api/public/site`, at a fixed rate for a fixed time.
- Record on a 2 GB VM: memory per container at rest and under load, p50 and p95 latency, and API startup time. Write the numbers into #798.

## 2. Postgres for small servers

Ship tuned settings in the production and quickstart compose files, sized for 2 GB and documented for 4 GB and 8 GB:

| Setting | Stock today | 2 GB target |
|---|---|---|
| `shared_buffers` | 128 MB | about 25% of RAM |
| `effective_cache_size` | 4 GB | about 50 to 75% of RAM |
| `random_page_cost` | 4 | 1.1 for SSDs |
| `jit` | on | off |
| `work_mem` | 4 MB | sized against `max_connections` |

Re-run the baseline with the new settings and keep only what improves p95 or holds it while lowering memory. Document the per-RAM values in `docs/deploy-in-production.md`.

## Done when

- The baseline and the after numbers are recorded in #798.
- The compose files carry the settings that measured better, and the deploy doc lists them per RAM size.

Start with docker-compose.prod.yml and the quickstart/ configuration, then inspect the public delivery endpoints for the list, slug entry, and GET /api/public/site. Run the repeatable load against a 2 GB VM, record baseline and revised measurements in #798, and document the measured Postgres settings for 2 GB, 4 GB, and 8 GB in docs/deploy-in-production.md.

Written by the indexing model from the issue text.