The PostgreSQL Long-Running Query twin ignores the program/login opt-out knob: the setting is visible, editable and read back, and does nothing on a PostgreSQL target #3743

The gap

#3734 gave the Long-Running Query alert an opt-out knob — longRunningQueryExcludedProgramNamePrefixes (prefix, case-insensitive) and longRunningQueryExcludedLogins (exact, case-insensitive), applied in the read ahead of the row cap and counted by arm — and #3736 gave it a Darling store home (V135) and the get_alert_settings / update_alert_settings twins. Both PRs state the same limit: "Does not apply the knob to the PostgreSQL LRQ twin (DarlingWorker.EvaluatePgLongRunningQueryAsync) — stated in the Darling README." The README says it (Darling/README.md:473: "…the PostgreSQL twin does not consult the knob").

So on a PostgreSQL target the knob is a setting the operator can see, edit and read back through the MCP, and it does nothing. A monitored PostgreSQL server whose longest sessions are a permanent replication or ETL worker under a service role fills the five-row page with them every sweep, and the operator's exclusion — which works on the SQL Server twin from the same settings row — is silently ignored.

What is verified at source (origin/dev 98d52fe)

• Darling/PerformanceMonitor.Darling.Service/DarlingWorker.cs:4783-4788 — the PostgreSQL twin's read call passes thresholdMs, now, recency, limit: alertSettings.LongRunningQueryMaxResults, excludeBackups: alertSettings.LongRunningQueryExcludeBackups, excludedDatabases: alertSettings.ExcludedDatabases — and nothing from the knob (LongRunningQueryExcludedProgramNamePrefixes / LongRunningQueryExcludedLogins do not appear in DarlingWorker*.cs).
• Darling/PerformanceMonitor.Darling.Storage/DarlingPgSessionStatesReader.cs:492 GetCurrentLongRunningSessionsAsync(... bool excludeBackups, IReadOnlyList<string>? excludedDatabases, ...) — no program/login parameters; the {0} switchable filter block (:468) carries only the excludeBackups arm (application_name NOT IN ('pg_dump', …)).
• The PostgreSQL row carries the two columns the knob needs: pg_stat_activity.application_name is the program_name twin and usename the login_name twin; the reader already filters on application_name for backups.

The fix shape

• Thread the knob into EvaluatePgLongRunningQueryAsync → GetCurrentLongRunningSessionsAsync, and apply it in the read ahead of LIMIT $4 through the shared LongRunningQueryExclusions.BuildSqlPredicates("s.application_name", "s.usename", firstParameterOrdinal: 5) — the same translation the two SQL Server reads use, so an entry means the same thing on both engines (%/_ escaped, prefix for programs, whole name for logins). Report excluded_by_program_prefix / excluded_by_login beside the rows as the SQL Server twin does, and render them in the PostgreSQL incident's context.
• The seeded defaults (SQLAgent - TSQL JobStep, the two NT AUTHORITY logins) name SQL Server internals with no PostgreSQL reading — they match nothing there, which is correct; the knob's []-excludes-nothing rule holds. Whether the PostgreSQL side wants its own seeds (a replication role, an autovacuum-style worker — though non-client backends are already out through backend_type) is a production read for the monitor seat, not this lane's guess.
• README :473 and the engine-coverage table drop the "does not consult the knob" sentence; PgLongRunningQueryTests (or the reader's parse census DarlingPgReadSqlParsesLiveTests) pins the predicates in the shipped SQL.

Descends from #3734 / #3736 (Q5 of #3653). Partial #3653 residue.