Fix #1048: stop alert engine fabricating 100% host CPU on Linux

[erikdarlingdata]

Problem

The reporter on #1048 installed the #1049 nightly and still saw the host-CPU alert on their OpenSUSE-hosted SQL Server.

#1049 corrected every path that reads CPU from the collected table (install/18 collector, install/47 views, Overview.cs/ResourceMetrics.cs chart reads). But the alert engine doesn't read that table — DatabaseService.NocHealth.GetCpuPercentAsync runs its own live query against sys.dm_os_ring_buffers and was never touched.

It computes other_cpu_percent = 100 - SystemIdle - ProcessUtilization. Since SystemIdle is always 0 on SQL Server on Linux, that returns 100 - sqlcpu. AlertHealthResult.TotalCpuPercent then sums to a permanent 100%, so AlertStateService's TotalCpuPercent >= CpuThresholdPercent check fires the host-CPU alert forever. The chart was fixed; the alert badge was not.

Fix

Apply the same Linux guard already used by install/18, RemoteCollectorService.Cpu, and FinOps.Inventory:

• Detect host_platform via sp_executesql behind an OBJECT_ID(N'sys.dm_os_host_info', N'V') check, so SQL 2016 never binds the 2017+ DMV.
• Return NULL for other_cpu_percent on Linux.

The existing TotalCpuPercent getter already falls back to the SQL-only figure when OtherCpuPercent is null, so the alert clears. Windows behavior is unchanged.

Scope

Dashboard-C#-only — no schema or installer change. The reporter can verify with just the next nightly Dashboard (no DB re-install needed).

Verification

• Rewritten query parses & runs on SQL 2022 — Windows path unchanged (SQL 0% / other 1%; Linux would yield NULL).
• Dashboard builds clean (0 warnings, 0 errors).
• Confirmed NocHealth.cs was the only remaining live SystemIdle computation in the Dashboard.
• Linux runtime behavior is the reporter's to confirm (no Linux SQL host available here), same as Fix #1048: stop reporting 100% host CPU on SQL Server on Linux #1049.

🤖 Generated with Claude Code