analyze_server for PostgreSQL targets — the inference engine answers 'what is wrong, ranked' for one engine only #3605

analyze_server — the diagnostic inference engine that turns raw telemetry into scored, persisted findings — is SQL-Server-only. A PostgreSQL target returns PostgresAnalysisNotApplicable (DarlingWorker.cs, three call sites). PG targets do have predictors (wraparound, xmin horizon, replication-slot outage) and a full read surface, but nothing that composes those signals into ranked findings the way the SQL Server engine does, and nothing feeding the analysis-findings store, notification cards, or the compare-two-periods workflow for PG.

The practical consequence: the product's highest-level answer — "what is wrong with this server, ranked" — exists for one engine and not the other, so the operator's workflow forks by engine exactly where it should converge. The MCP/AI surface feels this too: analyze_server and compare_analysis are the tools an assistant reaches for first, and on PG they return a shrug.

Scoping honestly: this is not one lane. The inference engine's fact families are SQL-Server-shaped (waits, plan cache, scheduler pressure), and a PG engine needs its own fact families with measured thresholds — statement regressions from pg_stat_statements deltas, autovacuum debt, bloat trajectory, wait fractions (per the ongoing scorer-recalibration work, folklore constants are not acceptable inputs), connection saturation, replication risk. The right first slice is probably: define the PG fact-family list, wire the persistence/read plumbing so PG findings flow through the SAME findings store and alert path, and ship two or three families end-to-end rather than all of them shallowly. Related runbook honesty: docs/postgres-first-target-runbook.md already tells users analysis does not exist for PG — that section should keep saying so until this lands, then stop (see the runbook staleness issue).