Record the two CHANGELOG entries for #3271

[erikdarlingdata]

#3271 merged at 15:10:23Z with its entry text in the PR body rather than in the file, per the convention that a lane PR does not touch CHANGELOG.md. Verified absent from [Unreleased] on dev before this change: a grep for 3267|3272|cpu_source returned zero. Without this splice, #3271's two changes ship in the next release undocumented.

Both entries go under ### Fixed, newest-first, with reference link definitions added beside their numeric neighbours.

The second entry cites #3271 rather than #3272. The false-Healthy defect was filed as #3272 and then folded into the same PR, and #3272 has since been rescoped to the open question of whether pg_blocking should feed a PostgreSQL card's blocking and deadlock counts — so its body no longer describes the change this entry records, and a reader following the link would land somewhere that contradicts it.

Not touched: the missing ## [3.6.0] section. That is #3242's scope and this PR deliberately stays out of it.

[claude]

Reviewed. This is a documentation-only splice into CHANGELOG.md — no code, SQL, or config changes, so Lite/Darling parity and the T-SQL style rules don't apply here.

Checked and confirmed:

• No duplicate [#3267]/[#3271] link definitions already present.
• Numeric link-reference block stays sorted (…Azure master-connected database_size_stats dies on a DBNull cast once sys.resource_stats has sibling rows #3262, Fleet cards: PostgreSQL targets always show null CPU/memory metrics - the reader only queries SQL Server metric views #3267, Fleet cards read a PostgreSQL target's instance CPU, and stop claiming Healthy for what they never measured (#3267, #3272) #3271).
• Entries are newest-first under ### Fixed, correctly placed above the pre-existing Azure master-connected database_size_stats dies on a DBNull cast once sys.resource_stats has sibling rows #3262 entry.
• Formatting matches house style (bold lead-in, em-dash, per-repo voice).
• Both entries' claims check out against the actual merged code: cpu_source/collect.pg_cpu_utilization exist in DarlingFleetReader.cs/DarlingPgCpuUtilizationReader.cs, and the ENGINE-discriminant Unknown-banding described in the second entry matches the doc comment in PerformanceMonitor.Common/ServerHealthBands.cs almost verbatim, backed by UnmeasuredMetricsAreNotHealthyTests.cs.
• The Fleet cards read a PostgreSQL target's instance CPU, and stop claiming Healthy for what they never measured (#3267, #3272) #3271-vs-Should the fleet card read pg_blocking / pg_deadlocks into a PostgreSQL target's blocking and deadlock counts? #3272 citation call is correct: Should the fleet card read pg_blocking / pg_deadlocks into a PostgreSQL target's blocking and deadlock counts? #3272 was folded into Fleet cards read a PostgreSQL target's instance CPU, and stop claiming Healthy for what they never measured (#3267, #3272) #3271's PR and has since been rescoped, so citing Fleet cards read a PostgreSQL target's instance CPU, and stop claiming Healthy for what they never measured (#3267, #3272) #3271 for the false-Healthy fix is the right link.

No issues found — LGTM.