fix: lower the client request-body budget so the size checks can trigger

[hetaoBackend]

Problem

max_request_body_bytes defaulted to 64 MiB, both as the client fallback and in the bundled MiniMax catalog. Real MiniMax channels reject much smaller bodies: about 28 MB direct and 16–18 MB on Bedrock. As a result, the pre-send body check (assertRequestBodyFits) and byte-based automatic compaction (serializedBytes > maxSerializedInputBytes) never fired before the provider answered 413.

Fix

• Default fallback (DEFAULT_MAX_REQUEST_BODY_BYTES) and MiniMax catalog M3/M3.1 budget: 16 MiB. This is the strictest channel; the managed client cannot tell which channel serves a request. A remote model snapshot that declares its own value still wins.
• MiniMax API-key path (minimax_api, a known direct channel): 28 MiB, via resolveMaxRequestBodyBytes.
• Custom providers keep their declared max_request_body_bytes and default to 16 MiB.
• Automatic compaction now starts at 90% of the budget (automaticCompactionByteTrigger). This leaves headroom between the footprint estimate and the final serialized body; the hard pre-send check stays at 100%.
• max_image_bytes_inline is unchanged.

Tests

• local-model-resolver.test.ts:
  • managed MiniMax resolves to 16 MiB;
  • minimax_api, and minimax + API-key source, resolve to 28 MiB;
  • a custom provider defaults to 16 MiB and honors an explicit 100 MiB;
  • invalid or missing values fall back to 16 MiB.
• context-compaction.test.ts: the 90% trigger values.
• Updated default expectations in model-ref.test.ts and config/test/builtin-model-fallback.test.ts.
• pnpm typecheck, the capability suite (214 files, 5391 passed) and check:source pass.

Open questions

• Are 28 MB and 16–18 MB measured as serialized request-body JSON bytes, which is what the client checks?
• Should the server model catalog publish a per-channel max_request_body_bytes so the managed path can use more than 16 MiB?

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}