Fix strict-mode wire schema to actually be strict-tool-use compatible

[exactml]

Summary

This fixes a production regression from v0.2.3, which made every Anthropic-backed review fail 100% of the time.

• AnthropicProvider.generate_structured's strict: true tool definition was rejected outright by the API (400 invalid_request_error: "For 'number' type, properties maximum, minimum are not supported") on every single call, because Finding.confidence's ge=0.0, le=1.0 and _FindingsResponse.findings' max_length render as minimum/maximum/maxItems -- keywords outside strict tool use's supported JSON Schema subset. Unlike the pre-v0.2.3 failure mode (intermittent, sometimes worked), this failed deterministically every time, making v0.2.3 strictly worse than v0.2.2 for anyone with an Anthropic models.reviewer configured.
• _strict_input_schema now adapts the wire schema before sending it: strips confirmed-unsupported keywords (minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf, minLength, maxLength, maxItems, uniqueItems), rewrites a nullable field's anyOf: [{type: X}, {type: "null"}] (pydantic's rendering of X | None) into the {"type": [X, "null"]} form Anthropic's docs describe, and validates additionalProperties: false wherever it appears. Pydantic's own validation of the response still enforces the stripped bounds locally -- only the server-side guarantee for that bound is lost, not the check itself.
• Design note, since the first draft of this fix used a denylist and it already had a gap (missing uniqueItems, caught in review): the final version checks every schema keyword against two explicit lists -- confirmed-unsupported (stripped) and confirmed-supported (kept) -- and raises ValueError immediately on anything in neither. A keyword nobody's vetted yet now fails a test the moment a new constrained field is added, instead of silently shipping to production the way this regression did.
• Includes a regression test built directly against the real _FindingsResponse schema, plus tests for the allowlist's fail-loud behavior on an unvetted keyword (e.g. pattern) and the uniqueItems gap specifically.

Relates to #96 -- not a new issue, this is the correction to the fix from #99.

Test plan

• make lint -- clean
• make test -- 165 passed, including:
  • a regression test against the real _FindingsResponse schema asserting no forbidden keyword leaks into the sent request
  • the stripped bounds (confidence's ge/le) still reject an out-of-range value locally, proving the server-side guarantee loss doesn't become a client-side gap too
  • an unvetted keyword (e.g. pattern) raises ValueError before any request is sent
  • uniqueItems (the exact gap found in review of the first draft) is confirmed stripped
• Once released, re-verify against a live PR with a non-trivial diff (the failure only reproduces with an actual Anthropic API call)

🤖 Generated with Claude Code