Close the gaps a four-distro cold install matrix found

[GuanzhouSong]

How this was found

Four testers with no prior DocumentDB knowledge installed from the live site using the real documentdb.io repository, in Docker, across the whole support matrix:

Tester	Coverage	Score
A	Ubuntu 24.04 full stack — meta + PG17	4/5
B	RHEL 9 full stack — meta + PG17, deliberately skipping CRB	3/5
C	Ubuntu 22.04, Debian 11/12/13	3/5
D	RHEL 8, and PostgreSQL 16 on the paved road	2.5/5

Every runtime claim the site makes held up — the 0.0.0.0:10260 gateway vs 127.0.0.1:9700+N PostgreSQL split, log and config paths, the no-systemd nohup fallback, and the corrected uninstall. Both full-stack paths reached an inserted-and-queried document. The failures were entirely in what the pages say.

What they found, and what this changes

1. Static install commands existed for two distributions out of seven. Three testers independently hit this. Everything except Ubuntu 24.04 and RHEL 9 lives behind the JavaScript Package Finder — invisible to curl, which is exactly the headless audience a Linux packages page serves. Testers guessed ubuntu22, deb11, deb12, rhel8 from the two worked examples. They guessed right; that is luck. Adds a component-and-package table for every distribution.

2. PostgreSQL 16 on the paved road silently double-downgrades. documentdb-16 does not exist, so the advertised full stack degrades to a bare extension, and postgresql-16-documentdb is served at 0.114 while 17/18 are at 0.116 in the same repository. Nothing said so, and every version example on the page read 0.116. Now stated inline, plus a which-version-per-tier table.

3. The CRB line had a command but no reason. With CRB disabled, tester B reproduced the failure exactly — 76 lines of GDAL candidates and nothing provides libqhull_r.so.7, which names GDAL but never the missing repository. The chain is now explained so nobody trims that line as noise.

4. The documentdb meta package was named but never explained. It depends on documentdb-18; testers learned that from apt-cache depends, not from us.

5. No way to reach the managed PostgreSQL was documented — despite Upgrading instructing ALTER EXTENSION. It is peer auth as documentdb-local over a per-major socket; two testers failed at this before reverse-engineering it. Now documented and verified:

\
sudo -u documentdb-local psql -h /run/documentdb-local/18/postgresql -p 9718 -d postgres
documentdb_extended_rum | 0.116-0
documentdb_core | 0.116-0
documentdb | 0.116-0
\\

6. Debian 13 does not install from this repository. apt.postgresql.org also ships DocumentDB for Trixie, and its 0.114-0-1.pgdg13+1 outranks our 0.114-0. I verified the scope: PGDG carries DocumentDB for trixie only — bullseye, bookworm, jammy and noble have zero. Now documented, with how to pin.

7. Debian 11 / PostgreSQL 18 moved out of the troubleshooting footer — that is where a newcomer picking "newest" lands. The site's prediction was verified correct: Depends: postgresql-18-postgis-3 but it is not installable.

Validation

130 tests, tsc --noEmit, and next build all pass; every new string verified present in the rendered guide.

Claims tested against reality rather than assumed — the CRB failure mode, the Debian 11 exclusion, the PGDG overlap, the meta's dependency, and the psql route were each executed in a container.

[guanzhousongmicrosoft]

Validated by a four-distro cold install matrix run locally in Docker against the live site and the real package repository. Every runtime claim verified; the documentation gaps this PR closes were each reproduced (CRB/libqhull failure, Debian 11 PG18 exclusion, PGDG overlap on Trixie, the meta package dependency, and the psql route). CI green.