Merge pull request erikdarlingdata#3275 from erikdarlingdata/chore/changelog-3271

Record the two CHANGELOG entries for erikdarlingdata#3271

Author: erikdarlingdata

CHANGELOG.md

@@ -161,6 +161,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - **Lite's portable ZIP is self-contained, which HALVED it** ([#2501]) - `Publish Lite` is now `-r win-x64 --self-contained` in both `build.yml` and `nightly.yml`, so neither Lite artifact has a .NET prerequisite any more and the failure [#2489] documented stops existing: a tester who unzips onto a stock Windows Server no longer meets the .NET host's bare `You must install .NET to run this application` before a line of our code runs. **The size went the opposite way from what bundling a runtime suggests.** The old publish was RID-agnostic, so it copied every platform its packages ship - **537 MB of `runtimes\` on a 565 MB tree** (osx 130, linux-x64 116, linux-arm64 70, win-arm64 56, then win-x86, musl, loongarch64 and riscv64), of which only the **52 MB `win-x64`** folder could ever load on Windows. `DuckDB.NET.Bindings.Full` is most of it, SkiaSharp and SqlClient behind it. Dropping ~485 MB of unloadable native payload beats the cost of bundling .NET, WPF and ASP.NET Core by roughly two to one: measured on one commit and one SDK, **565 MB tree / 212.7 MB zipped becomes 277 MB / 114.2 MB**. It matters most for the **nightly** ZIP, which is the UAT download and is not offered as a `Setup.exe` at all. **A RID-specific publish needed two more files than the flag.** `Lite/packages.lock.json` had only a `net10.0-windows7.0` target, and a RID restore adds `net10.0-windows7.0/win-x64` to it - after which the `dotnet restore --locked-mode` that BOTH workflows run before the publish fails `NU1004: the project's runtime identifiers have changed`, because locked mode compares the PROJECT's RID set (empty) against the lock file's (win-x64). Reproduced locally; that is a red CI run on every PR, not the future `--no-restore` trap it was filed as. The fix is `<RuntimeIdentifiers>win-x64</RuntimeIdentifiers>` in `PerformanceMonitorLite.csproj`, so the project itself asks for that graph and one committed lock file satisfies the RID-less locked-mode restore and the RID publish alike; `RuntimeIdentifiers` (plural) sets no RID on the build, so a plain `dotnet build` stays RID-agnostic and `Lite.Tests` is untouched. **SignPath needed nothing** - the `Lite` artifact-configuration slug already receives both shapes today, and the signed re-zip reads `signed/Lite/*`, inheriting whatever shape `publish/Lite` has. Auto-update is unaffected; the ZIP is not a Velopack channel. `LiteRuntimePrerequisiteDocsTests` went red on the flag alone (3 of its 7 facts) and was rewritten to state every claim BOTH ways round: [#2499]'s version asserted only that the docs DID name the runtimes, so two of its facts stayed green while the prose went stale. It now also derives the lock file's RID coverage from the `-r` flags in the workflows, and every new assertion was proven red with its fix reverted.
 
 ### Fixed
+- **Fleet cards now report a PostgreSQL/Aurora target's instance CPU** ([#3267]) - `get_fleet_overview`, `/api/fleet` and the viewer's Overview cards read CPU only from the SQL Server ring-buffer table, so every PostgreSQL card carried a null CPU and an Unknown band permanently. Instance CPU is now read from `collect.pg_cpu_utilization` (Performance Insights) through the same severity ladder, and a new `cpu_source` field on each card names which collector answered — separating a reading that has not arrived from a PostgreSQL target for which none is collected at all. The transfer of `CpuSeverity`'s cutoffs was measured rather than assumed: Performance Insights' `os.cpuUtilization.total.avg` and the ring buffer's `100 - SystemIdle` share quantity, denominator and averaging window, and across a 50-target PostgreSQL fleet the median reads 8.4% with 0.48% of samples reaching 80. Memory, buffer pool and the threads block stay null on those cards: no PostgreSQL equivalent is collected and none is invented.
+- **A server card no longer reports a metric as Healthy when nothing measured it** ([#3271]) - the memory-pressure, blocking and deadlock bands read off SQL Server DMV captures a PostgreSQL target has no row in, and their non-nullable inputs meant the resulting zeros banded Healthy — a green dot claiming health beside a `deadlock_source` already reporting the count as structurally uncountable. All three now band Unknown for an absent source, as CPU and worker threads already did, and the discriminant is the target's ENGINE rather than collector state, so a SQL Server whose collector is permission-denied still bands on its own failure count. The published counts are unchanged, so the fleet totals and their coverage denominator still reconcile, and an Unknown can move neither a band nor the worst-first ranking.
 - **Azure master-connected size collection no longer dies the moment sys.resource_stats has sibling rows** ([#3262]) - #2643's sibling arm deliberately emits rows whose database_id, file_id and physical_name are NULL, because sys.resource_stats carries per-database sizes with no per-file breakdown, and ReadAsync read exactly those three ordinals unguarded - so the first sibling row, which appears once the view finishes ingesting (roughly an hour after database creation, which is why every fresh-server validation window missed it), threw a DBNull cast that aborted the whole read, master's own file rows included, permanently, on every master-connected Azure target. The reader now passes the NULLs through as nullable Row fields; Lite's DuckDB store drops its NOT NULL on the three columns (schema v57, dropping the table's index first per the #2748 ALTER COLUMN trap; Darling's Postgres store was always nullable here); and the has_user_databases inventory screen in both SKUs' collection health admits sibling rows through an IS NULL arm, since on a master-connected Azure target they are the only evidence of user databases the store has. A reader-level seam test now drives ReadAsync over the sibling shape the arm's own tests always pinned, proven red against the unfixed reader.
 - **The Query Store tab's first/last-execution columns had no row-level value pin — the coverage shape that let the #3207/#3221 clock-frame defects ship** ([#3253]) - the ConsumedTimestampFrameDisciplineTests census proves the two properties reach the stored-UTC renderer by NAME, not that the right value comes out of the row, so a cross-wired or misformatted property would pass every existing test. Both stamps now carry #3252's machine-independent pin — expected derived through the same ViewerTimeHelper.ForDisplay conversion the renderer uses, distinct inputs so first wired to last fails, and the empty-for-null contract — and the ViewerQueryStoreHistoryRow drill-down twins, the same naive-UTC query_store_stats stamps rendered through the same conversion one window over, are pinned the same way rather than left as the next #3248. Both pins were proven red against a temporarily cross-wired property on a UTC-4 machine, where the derived expectation genuinely converts.
 - **A test pinned the Query Store regression row's last-execution display as the raw server clock, which after the #3207 clock-frame work fails on any non-UTC machine and verifies nothing on CI's UTC runners** ([#3248]) - the row model converts the stored naive-UTC stamp to the display mode, so the pinned literal agreed with it only where that conversion is the identity. The expected string is now derived through the same ViewerTimeHelper.ForDisplay conversion the renderer uses - the sibling display tests' established pattern - and the test is renamed to the contract it asserts.
@@ -3615,3 +3617,5 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 [#3253]: https://github.com/erikdarlingdata/PerformanceMonitor/issues/3253
 [#3261]: https://github.com/erikdarlingdata/PerformanceMonitor/issues/3261
 [#3262]: https://github.com/erikdarlingdata/PerformanceMonitor/issues/3262
+[#3267]: https://github.com/erikdarlingdata/PerformanceMonitor/issues/3267
+[#3271]: https://github.com/erikdarlingdata/PerformanceMonitor/issues/3271