Improve documentation for website integration (PoC for exporter docs pattern)

[nicolastakashi]

Context

We're starting an effort to pull exporter documentation into the Prometheus website at build time, the same way prometheus/prometheus and prometheus/alertmanager docs already work. Right now Kapa.ai often can't answer "how do I monitor X" even when we ship an exporter for it, because our exporter docs aren't structured for that.

postgres_exporter is the proof-of-concept. The goal isn't just to fix its docs, it's to extract a reusable scaffold we can apply to the rest of the exporter ecosystem afterward, working with #prometheus-docs-wg on structure and placement.

Proposed structure

1. Overview: what it monitors, what it doesn't, supported PostgreSQL versions.
2. Getting started: Docker/binary quick start (exists), plus a how to Kubernetes/Helm example (missing).
3. Configuration reference: flags, env vars, auth_modules, custom queries, with current vs. deprecated options clearly separated (today they're mixed with no migration guidance).
4. Security: credential handling, non-superuser setup via pg_monitor/pg_read_all_stats, TLS via web.config.file. Mostly exists but buried or under-explained.
5. Operations (new): running the exporter, scaling (single-target sidecar vs. multi-target /probe, sharding across instances), resource sizing, collection timeout tuning, and cardinality management for high-cardinality collectors like stat_statements and stat_activity.
6. Troubleshooting (missing): connection pool exhaustion, pg_stat* permission errors, unsupported/variant Postgres builds (Greenplum, RDS, Aurora).
7. Upgrading: real migration guidance for deprecated flags, not just a DEPRECATED tag.
8. Reference dashboards and alerts: none exist today; likely the cheapest addition for a website landing page. (Mixins)
9. Metrics reference: generated from collector source rather than hand-maintained, so it can't drift from the code. Easier once we have Weaver schemas for the exporter's metrics.

Other gaps

Managed Postgres (RDS/Aurora/Cloud SQL) guidance, since that's the main multi-target use case; HA/multi-replica behavior for stat_replication/replication_slots; and version-gated collectors/flags (e.g. stat_checkpointer needs PG 17+).