fix(think): strip maxItems for the google provider
On the google BYO lane, litellm passes our JSON Schema verbatim as Gemini's responseJsonSchema. Gemini compiles maxItems into a bounded decoding grammar with an undocumented, additive, whole-schema budget; over budget it returns a bare 400 INVALID_ARGUMENT naming no keyword, path, or limit. 7 of the 8 shipped schemas carrying maxItems are rejected as-is; all 8 pass stripped. Because sense is the floor talent (schedule: segment, priority: 5), its 400 meant no segment talent ran at all on google while brain health still read "sol can think".
The root cause is that the whole-schema grammar budget is additive across every bounded array and scales with N x item complexity, not a per-keyword or per-array limit. Tuning individual maxItems values is therefore not the fix, no schema value was changed, and minItems is free.
The change adds one keyword to the google row of STRICT_UNSUPPORTED_KEYWORDS, corrects the provider comments, and updates the tests that previously asserted the broken behavior.
Residual risk: stripping maxItems from the google request means Gemini is no longer grammar-constrained at generation time, while models.py still validates the response against the canonical schema and x-truncate has no array path. The failure mode changes shape rather than disappearing: before, 400 INVALID_ARGUMENT on every segment, always; after, a segment dense enough to produce more than 96 entities raises SchemaValidationError instead of being grammar-clamped. That is a strictly better trade, a loud, specific, occasional failure replacing a silent, total one, and it is the posture Anthropic already ships under.
Second-order: this makes the entire segment talent chain reachable on the google lane for the first time. Entities, facets, screen, speaker attribution, and segment summaries have never executed there.