docs: surface non-Neon Postgres support and document upstream auth compatibility

[andybons]

What

The Postgres data plane works with any Postgres provider via resolver: static — only the dynamic per-branch minting is Neon-specific — but the docs leaned Neon-forward and underplayed that. This makes it discoverable and documents the one real compatibility constraint.

• concepts/08-postgres-data-plane.md — new ## Using a non-Neon Postgres server subsection (any TLS-reachable Postgres works via resolver: static with a fixed password from any credential source; covers RDS, Cloud SQL, Supabase, self-hosted), with a validated config snippet. Plus a ### Upstream authentication compatibility subsection.
• guides/13-postgres-neon.md — one sentence flagging the guide as Neon-specific and linking the new subsection.
• reference/02-config-file.md — light tweak noting static works with any Postgres server.

Upstream-auth claim — verified against code

Documented what the code actually does, not an assumption: authenticateSCRAM (proxy/postgres.go:289-377) accepts only AuthenticationSASL + the SCRAM-SHA-256 mechanism; any other method (MD5, cleartext, trust) hits the default case and errors "upstream requested unsupported authentication". So it's SCRAM-SHA-256 only on the upstream leg — documented with the managed-provider guidance (RDS/Cloud SQL/Supabase/PG10+ all default to it; MD5-only/trust servers won't work).

Docs-only; no code changes, no CHANGELOG bump (documents existing behavior). Config snippet validated via gatekeeper.LoadConfig; go build/go vet pass.

[claude]

Claude finished @andybons's task in 2m 19s —— View job

---

Review complete

• Gather context (PR diff, changed files)
• Verify claims against code (SCRAM-only upstream auth, static resolver caching, config snippet validity)
• Post findings

Summary

Docs-only PR, no code changes. I verified every factual claim against the current code and it all checks out:

• SCRAM-SHA-256-only upstream auth (concepts/08-postgres-data-plane.md, new "Upstream authentication compatibility" section): confirmed in authenticateSCRAM (proxy/postgres.go:289-377) — the default case on the initial auth message (proxy/postgres.go:300-302) errors on anything but AuthenticationSASL, and the mechanism loop (proxy/postgres.go:303-312) requires SCRAM-SHA-256 specifically.
• Generic client-facing error, detailed error only logged: confirmed in serveAuthenticated (proxy/postgres.go:866-891) — the client always gets "could not authenticate to upstream database" (502/28P01) while the real error (including stage: resolve/upstream_auth/upstream_connect) is only slog.Debug-logged server-side.
• static resolver fetches once at startup, no rotation without restart: confirmed in gatekeeper.go:626-641 (loadPostgresCredential) — the source is Fetch'd once and wrapped in NewStaticPostgresResolver, matching the existing comment at gatekeeper.go:601. The comparison to env/static/secret-manager HTTP-plane sources is accurate too — none of those implement RefreshingSource (credentialsource/source.go:14-20); only process, gcp-service-account, and github-app do.
• Config snippet (new example in 08-postgres-data-plane.md): every field (postgres.port, tls.ca_cert/ca_key, credentials[].host/grant/postgres.resolver/source.type/source.var, network.policy/allow) matches the current Config struct tags in config.go. Parses cleanly via gatekeeper.LoadConfig (no proxy: block needed since ParseConfig does a plain YAML unmarshal with no required-field validation at that layer).
• Anchor link in guides/13-postgres-neon.md (#using-a-non-neon-postgres-server) follows the same slug convention used by every other cross-doc anchor link in this repo.

No security, correctness, or consistency issues found. Nothing to flag.