get_pg_server_config_changes is blind to per-database and per-role overrides: an ALTER DATABASE … SET or ALTER ROLE … SET change never appears (derivative of #3691 / V138) #3937

Derivative of #3691 lane 46 (#3882, rung V138). #3882 taught pg_server_config to carry per-database and per-role overrides from pg_db_role_setting and made every server-wide read exclude them. For ConfigChangesSql (Darling/PerformanceMonitor.Darling.Storage/DarlingPgServerConfigReader.cs:178) the exclusion was necessary: its LAG … PARTITION BY c.name would put an override row in the server-wide row's partition and invent a change on every snapshot. The side effect is that get_pg_server_config_changes can't see an ALTER DATABASE … SET or ALTER ROLE … SET change at all. An operator asking "what changed the day this tenant got slow" is told nothing changed. The reader's own comment calls this "a later brief". This is that brief.

Shape:

• Server-wide change rows stay byte-identical.
• Add a scoped arm, partitioned by (name, database_name, role_name).
• The scoped arm must also see an override appearing (SET) and disappearing (RESET). Today's LAG shape can see neither, because prev_time IS NOT NULL hides a first appearance and an absent row is never read.
• The rows present on the first V138 snapshot are baseline, not changes. The cut is darling_schema_version.applied_at for version 138.
• The tool and the web endpoint carry scope fields only on scoped rows.

No rung. Not in any fence. Lane 48, claimed by pm-wave-worker.