Nine PostgreSQL collectors are readable only from the Windows Viewer — the MCP and web surfaces cannot see them #2629

Found while exercising every read tool against the self-hosted rig.

The gap

Nine PostgreSQL collectors have a WPF Viewer panel and nothing else. No MCP tool, no web read endpoint:

Thirteen get_pg_* reads are served. These nine are not among them, and the web POSTGRES_TABS registry carries the same thirteen.

Why it matters more than a missing endpoint

The Viewer is Windows-only WPF. Every one of these is collected on a Linux or macOS host and then unreadable from that host — and unreadable by an agent anywhere, which is the surface this product is differentiated on. We are paying the collection cost on every cycle and shipping the answer to one GUI.

It is sharpest for pg_wait_sampling. #2625 just shipped a message that tells a stock-PostgreSQL operator, correctly, that pg_wait_stats is Aurora-only and pg_wait_sampling answers the same question. It points at a panel the MCP cannot read. On a non-Aurora target "why is this slow" now has an answer that is only visible if you are sitting at a Windows machine.

pg_index_bloat is the same shape: #2617 and #2622 were both spent getting it to return rows, and it returned 160 of them measuring 89.6% average leaf density — into a table nothing but the Viewer queries.

Suggested order

By what question each one closes, not by table size:

1. pg_wait_sampling — waits by queryid. The one Self-hosted PostgreSQL has no top-queries answer at all: pg_statement_stats is Aurora-only #2625 explicitly promises, and the primary "why is it slow" answer on every non-Aurora target.
2. pg_kernel_stats — OS CPU and disk per queryid. Pairs with the above: elapsed vs. on-CPU is the first split any tuning question needs.
3. pg_predicate_stats — predicate selectivity, i.e. which columns are actually filtered on and how well. Index-candidate evidence.
4. pg_index_bloat — measured leaf density and fragmentation.
5. pg_column_stats — the distribution facts behind a plan shape.
6. pg_buffer_usage, pg_extension_availability, pg_lock_stats, pg_write_stats.

Each needs its store reader, its MCP tool, its web dispatch entry, its POSTGRES_TABS entry, the ServerPageTabsTests read-to-collector map, and the MCP inventory ratchet — the registration set is known and mechanical.

The guard this needs

A test asserting every PostgreSQL collector that has a Viewer panel also has a served read. Nine of them drifted in one at a time, each individually reasonable, and nothing was watching the aggregate. Whatever lands first should bring that guard with it, or the tenth will do the same thing.