MCP budget: get_pg_io_trend's default call now fits the 32 KB budget (#4198)

[erikdarlingdata]

Part of #4198.

Why

get_pg_io_trend's point is the widest in the trend family. It has 28 numeric/boolean fields: read/write/extend
rates, cache-hit ratio, per-op latency, several tracking flags. There is no text field to truncate.

Every trend tool's default (auto-sized) call shares one 200-point target, TrendBuckets.McpPointBudget, when the
caller leaves bucket_minutes to the tool. That fits most of the family. But get_pg_io_trend's wide point puts
a default 24-hour, one-series call's 10-minute bucketing at 145 points. That measured 56-59 KB. This held both on
a production store and on this PR's own live fixture. It is well over the shared McpResponseBudget.DefaultBytes
target of 32 KB (#4198).

What changes

• PerformanceMonitor.Common/Mcp/TrendBuckets.cs: a new TrendBudget.Mcp(autoPoints, maxPoints) overload.
  Also TrendBuckets.PgIoMcpAutoPoints (70), get_pg_io_trend's own, narrower MCP auto-sizing target. Its doc
  comment records the measured bytes/point and the window sweep it was checked against. This keeps Trend tools return every raw point: get_file_io_trend sends 12,451 points / 1.4 MB for one server at defaults, more than an LLM client's context #3897's
  design intact: the read's own cap on an explicit bucket_minutes, PgIoMaxPoints (650), is untouched. So is
  the one-arg TrendBudget.Mcp(maxPoints) factory every other trend tool uses.
• Darling/PerformanceMonitor.Darling.Service/Mcp/DarlingMcpPgTrendTools.cs: get_pg_io_trend's MCP entry point
  now passes TrendBudget.Mcp(PgIoMcpAutoPoints, PgIoMaxPoints) instead of TrendBudget.Mcp(PgIoMaxPoints).
• The web viewer's /api/read mirror keeps calling the internal overload with TrendBudget.Chart directly. This
  PR does not touch the chart.
• A default call now lands on a 30-minute bucket for the 24-hour default window, instead of 10 minutes. Other
  windows get correspondingly wider, still auto-sized, ladder-picked buckets too.
• No tool description or parameter text changed. Darling/Darling.Tests/McpToolsListBudget/DarlingMcpPgTrendTools.txt
  needed no edit.
• New file: Darling/Darling.Tests/PgIoTrendDefaultBudgetLiveTests.cs. It seeds one (backend_type, context) pair
  at one-minute cadence for just over a day. It calls the tool with every argument defaulted, the literal default
  call, and asserts the UTF-8 byte count stays under McpResponseBudget.DefaultBytes. It fails on the pre-fix
  shape and passes on the fixed one. A second assertion in the same test confirms an explicit bucket_minutes
  still returns the full window's points, unaffected by the narrower default target.

Test plan

Rig: reused the stopped rig-ta rig (port 55976, already UTC). Dropped and recreated darlingtest and probe
first, since a prior lane had left data there.

Measured bytes, get_pg_io_trend, default call (24h, one series), on this PR's live fixture:

• Before: 145 points, 59.0 KB (60,456 bytes), over the 32 KB budget. Matches the roughly 56 KB
  production-store measurement in the brief.
• After: 48 points, 21.5 KB (22,016 bytes), under budget.
• Explicit bucket_minutes is unaffected. TrendPayloadBudgetLiveTests' cap-side case is 168h at the
  narrowest width the 650-point cap admits. It still measures 631 points / 248.6 KB, same as before this
  change.
• No Lite twin: Lite does not monitor PostgreSQL, so this tool, and every get_pg_* tool, has no Lite surface.
  Skipped the common brief's Lite steps and the Lite.Tests run, per this lane's own brief.

Targeted classes (rig, DARLING_TEST_PG against rig-ta):

• PgIoTrendDefaultBudgetLiveTests (new): 1/1 passed after the fix.
• TrendPayloadBudgetLiveTests: passed clean on the run kept as final. Two earlier runs each failed once, on
  a different tool's line each time: get_file_io_trend, then get_pg_io_trend. Both failures were a
  connection-level "Exception while reading from stream", not a size assertion. This fixture seeds a
  600-file, 300-tenant-database series, and that heavy seeding looks like the real cause, not a
  get_pg_io_trend-specific defect. A clean rerun on a freshly recreated darlingtest passed all tools,
  including get_pg_io_trend at every window.
• TrendBucketingLiveTests: 6/6 passed. All calls there use an explicit bucket_minutes, so this change
  cannot affect them, and the pass confirms that.
• TrendBucketsTests (unit, no rig): 37/37 passed.

Full suite, once, after merging origin/dev (clean merge) and recreating darlingtest:

• Darling.Tests: Total 13,856, Errors 0, Failed 2, Skipped 47 (expected env-gated fixtures), Not Run 1,
  625.8s. Build: 0 Warning(s), 0 Error(s).
• The 2 failures are ServerListAndSummaryPlanShapeTests.TheShippedReads_TouchFarFewerChunks_AndReturnTheSame NewestCollection_AgainstDevPostgres and CaptureDownChunkOrderTests.TheShippedRead_ExecutesOnlyTheNewestChunk_ AndTheNewestRunDecides_AgainstDevPostgres. Both are TimescaleDB chunk-exclusion EXPLAIN-plan-shape assertions
  on collect.collection_log. That is a subsystem this PR's diff does not touch: server-list/summary reads and
  collection-log chunk pruning, not trend reads. I reproduced both deterministically alone on rig-ta. They are
  pre-existing: dev's own latest CI Build run (36108125880, 2026-09-25T07:32:06Z) shows 0 failures across all
  three Darling PG test shards, 13,855 tests total. The most likely cause is a TimescaleDB build or version
  difference between this reused rig and CI's freshly provisioned one. It sits outside this lane's
  get_pg_io_trend brief, in a subsystem I have no context on. I am flagging it for the coordinator instead of
  fixing it here.
• Lite.Tests: not run. This tool has no Lite twin, because Lite does not monitor PostgreSQL.

CHANGELOG entry

SECTION: Fixed
ENTRY:

• get_pg_io_trend's default call now fits the MCP response budget ([MCP budget: get_pg_io_trend's default call now fits the 32 KB budget (#4198) #4263]): The default 24-hour call
  measured 56-59 KB. Its point is the widest in the trend family, over the 32 KB budget every MCP read
  tool's defaults now target (MCP read tools have no default response-size budget: at default arguments 12 tools return >50 KB and 3 return >100 KB for one server, more than an agent client's per-result cap #4198). The default call now buckets to 30 minutes instead of 10, measuring
  under 22 KB. An explicit bucket_minutes argument is unaffected and still reaches the tool's existing cap.
  REF:
  [MCP budget: get_pg_io_trend's default call now fits the 32 KB budget (#4198) #4263]: MCP budget: get_pg_io_trend's default call now fits the 32 KB budget (#4198) #4263

Generated with Claude Code

https://claude.ai/code/session_01TszxYhJJbTEh4LrZ56NYo3