Revert the 32KB packet size — it caused a fleet-wide error burst (#2164)

CHANGELOG.md

@@ -21,8 +21,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Changed
 
-- **Monitored-server connections use 32 KB TDS packets instead of the 8 KB default** ([#2164]) - the heavy collectors read rows carrying query text and execution-plan XML, and the client reads each row whole, so per-packet overhead is paid against payloads hundreds of KB wide. New per-database timing (open vs drain) measured on a cross-region fleet showed effective throughput tracking LOB size rather than total bytes: a database averaging ~180 KB per row moved 256 KB/s while one averaging ~41 KB per row moved 1,080 KB/s over the same link with the same code. Fewer, larger packets attack exactly that. A server that dislikes the larger size negotiates down rather than failing.
-
 - **Force-plan findings carry a machine-first verdict for MCP consumers** ([#2138]; Erik: agents will read these more than people) - analyze_server and get_analysis_findings (both apps) now emit structured_remediation alongside the copy-paste command: per target, eligible plus NAMED blockers (parameter_sensitivity_cofired, secondary_replica_evidence), the evidence numbers, join keys, and split force_sql / unforce_sql / verify_sql artifacts (verify asks both post-force questions: did the force stick, and the per-interval cost since). The blocker list comes from FactRemediation.ForcePlanBlockers - the ONE policy gate a future auto-force feature would consult, so what agents inspect today is what any later automation enforces, as a testable data contract. Computed at read time from the persisted targets (never persisted itself - one source of truth, no DTO mirror to forget).
 - **Plan-regression detection scores CPU as the primary signal and gates on absolute spend** ([#2138] Phase 0, the advise-only foundation for the auto-force-plan bot) - the old score was GREATEST(cpu ratio, duration ratio), so a plan whose CPU never moved could fire on duration alone - but duration is confounded by blocking, IO waits and machine contention that no plan choice caused, exactly the false positive a plan-forcing bot must never act on. Now a CPU regression scores at its own ratio; a duration-dominant one fires only when EXTREME (>= 4x) AND corroborated by at least mild CPU worsening (>= 1.25x), scored at HALF the duration ratio so it competes honestly with CPU-detected rows. A new noise floor drops offenders whose latest plan burned under 10 CPU-seconds across the whole 14-day comparison window - a 12x ratio on a query costing 12ms per run is sampling jitter, not a finding. The regressed-queries drill-down previously kept its OWN copy of the old score and could surface rows the fact never counted; it now runs the same scoring, in both SKUs, pinned by split-signal tests that move CPU and duration independently.
 - **The force-plan recommendation now warns when the regressed query is parameter-sensitive** ([#2138] gap 3) - each regressed_queries row carries a `parameter_sensitivity_cofired` flag, computed inside the drill-down with the PARAMETER_SENSITIVITY detector's own thresholds (one cached plan whose per-execution cost varies >= 10x across parameter values, same floors, same window) joined by query hash - so the flag can never claim evidence the detector would not report. A flagged target's force-plan preview gains a caution block naming the risk (forcing pins ONE shape for every parameter value; the population that preferred the other plan inherits the wrong one permanently, quietly, because a forced plan no longer recompiles away) and the gentler first levers (statistics updates; PSP optimization / Query Store hints on 2022+), and the copy-paste surface gets a compact two-line version of the same warning. Unflagged targets render byte-identically to before. This flag is also the standing gate for the future auto-force bot: a flagged target is never auto-forced. Both SKUs, pinned by live tests in both stores.

Darling/PerformanceMonitor.Darling.Service/MonitoredServerConnection.cs

@@ -8,7 +8,6 @@
 
 using System;
 using Microsoft.Data.SqlClient;
-using PerformanceMonitor.Common;
 
 namespace PerformanceMonitor.Darling.Service;
 
@@ -38,9 +37,6 @@ public static string BuildConnectionString(MonitoredServer server, string? resol
             MultipleActiveResultSets = true,
             ApplicationIntent = server.ReadOnlyIntent ? ApplicationIntent.ReadOnly : ApplicationIntent.ReadWrite,
             MultiSubnetFailover = server.MultiSubnetFailover,
-            /* #2164: fewer, larger TDS packets for the plan-XML/query-text payloads the heavy
-               collectors read. See CollectorTdsTuning for the measurement that motivated it. */
-            PacketSize = CollectorTdsTuning.MonitoredServerPacketSize,
         };
 
         /* Encrypt fail-closed: unknown/blank modes get Mandatory, matching Lite. */

Lite/Models/ServerConnection.cs

@@ -391,10 +391,7 @@ private string BuildConnectionString(ResolvedAuth auth)
             TrustServerCertificate = TrustServerCertificate,
             MultipleActiveResultSets = true,
             ApplicationIntent = ReadOnlyIntent ? ApplicationIntent.ReadOnly : ApplicationIntent.ReadWrite,
-            MultiSubnetFailover = MultiSubnetFailover,
-            /* #2164: fewer, larger TDS packets for the plan-XML/query-text payloads the heavy
-               collectors read. Shared constant so Lite and Darling cannot drift. */
-            PacketSize = PerformanceMonitor.Common.CollectorTdsTuning.MonitoredServerPacketSize
+            MultiSubnetFailover = MultiSubnetFailover
         };
 
         // Set encryption mode