Fleet cards: PostgreSQL targets always show null CPU/memory metrics - the reader only queries SQL Server metric views #3267

What

Every PostgreSQL/Aurora target's card in get_fleet_overview / /api/fleet carries cpu_percent, total_cpu_percent, memory_mb, buffer_pool_mb, and the threads block as null, always - healthy or not. #3236's field report noted the nulls beside the staleness false positive; the staleness half is fixed, and investigating it confirmed the nulls are a separate, structural gap, not a windowing artifact.

Mechanism (verified in source)

DarlingFleetReader reads metrics exclusively from the SQL Server tables:

• FleetCpuSql -> v_cpu_utilization_stats (= cpu_utilization_stats, the SQL Server ring-buffer collector's table)
• FleetMemorySql -> v_memory_stats
• FleetThreadsSql -> v_cpu_scheduler_stats
• FleetMemoryPressureSql -> v_memory_grant_stats

A PostgreSQL target has no rows in any of these; its instance CPU lands in collect.pg_cpu_utilization (the #2719 collector, populated from AWS Performance Insights on Aurora/RDS), which nothing in the fleet reader queries. The reads are NOT time-bounded (DISTINCT ON (server_id) ... ORDER BY collection_time DESC), so this is not a too-tight-window problem - there is no window to widen. The data exists in the store (get_pg_cpu_utilization serves it per server); the fleet card simply never looks.

Why it matters

On a pure-PG fleet the overview's per-server cards carry bands but no numbers, so an operator triaging from the fleet view gets Warning/Healthy labels with nothing behind them, and cpu_severity reads Unknown on every card. On a mixed fleet PG targets rank in the worst-first list only by collection/collector state, never by load.

Scope sketch (design needed, hence an issue rather than a rider on #3236)

• CPU: one more bounded cross-server read over collect.pg_cpu_utilization (latest sample per server), merged into the card for is_postgres targets; CpuSeverity thresholds presumably apply as-is to os.cpuUtilization.total.avg.
• Memory/threads/memory-pressure: no PG equivalent is collected today - decide whether those stay null (honest) or gain PG sources first.
• Self-hosted (non-Aurora) PG has no instance CPU source at all (Postgres High CPU alert isn't a light port — there's no instance-level CPU collector to alert on #2719's documented limitation), so the null stays legitimate there and the card should not fake it.