The buffer-composition drill-down's pressure block carries the fact's counts and observed span rather than a second copy of its per-second quotients, and its rounding helper reads whole — the two censuses #3795's pre-CI merge reddened on dev (#3691)

[erikdarlingdata]

What this fixes

#3795 (lane 29 of #3691, the buffer-composition drill-down) was hand-merged to dev before its CI finished; the Windows build and Darling PostgreSQL tests jobs then reddened on two repo-wide censuses that the lane's local harness had not carried. Both are census contracts about the SHAPE of what the drill-down publishes, not defects in what it reads or says; the fix is the smallest reshaping that satisfies each contract as written, and neither census is rostered or edited.

MeasurementContractCensusTests.EveryPerSecondPayloadKey_IsAReaderRateOrACSharpQuotient_OrIsNamed (rule 6): the drill-down's pressure block re-published the root fact's evictions_per_sec and buffers_alloc_per_sec as passthroughs (Round(summary.EvictionsPerSec)). The census requires a per-second payload key's value to be a reader rate of its own name, a C# quotient over a measured span, or a rostered key resting on a SQL alias or a => model member — and a fact-metadata passthrough is none of those shapes. Rather than roster it, the block now carries what the fact MEASURED — evictions, buffers_alloc, observed_ms — beside miss_share, hit_ratio_suppressed and cache_turnovers_per_hour. The per-second quotients are computed once in PgTargetFactCollector.Buffer.cs over observed time and remain the fact's to publish (get_analysis_facts source=pg_buffer; the advice prose states them); a copy under a per-second name was a second publication of one quotient, which is exactly what rule 6 exists to stop. The summary record's EvictionsPerSec/BuffersAllocPerSec became Evictions/BuffersAlloc/ObservedMs; the source pin now asserts no _per_sec = key in the drill-down's code.

TsqlConventionGuardTests.TheMemberScan_ReadsEveryDeclarationWhole: the expression-bodied Round(double? value) => value is { } v ? … : null made the member walk stop short at the { } pattern and the test asked for a KnownTruncatedRanges row. A block body with HasValue reads whole; no roster row.

What it does NOT change

The SQL, the dispatch, the kind/cold partitions, the four-arm sentence, the advice fold and every other payload key are as #3795 shipped them. No key, stub, migration, tool or scorer touched.

Tests

PgTargetBufferDrillDownTests updated in step (the source pin, the fixture, the e2e's pressure asserts — observed_ms pinned to the planted hour's range). Executed here before opening: the PG-target census set plus TsqlConventionGuardTests and MeasurementContractCensusTests — 204/204 with 0 skipped against a throwaway timescale/timescaledb:2.28.1-pg18 on desktop-linux (V136), the new e2e and lanes 2/16's e2es green; harness and container deleted. Builds: PerformanceMonitor.Analysis, PerformanceMonitor.Darling.Analysis, Darling.Tests, deprecated/Dashboard.Tests — 0 warnings.

Partial for #3691 (lane 29 census follow-up to #3795); do not close.

Which component(s) does this affect?

• Lite
• Darling
• Lite Tests
• Darling Tests
• SQL collection scripts
• Documentation
• Full Dashboard (deprecated)
• CLI Installer (deprecated)

How was this tested?

Above. No production store or fleet server was read.

Checklist

• I have read the contributing guide
• My code builds with zero warnings (dotnet build -c Debug)
• I have tested my changes against at least one SQL Server version (PostgreSQL-target change; the SQL Server pass reads none of the changed files)
• I have not introduced any hardcoded credentials or server names