pyproject pins pydantic>=2.0 but money-safety invariants need 2.4+ semantics #346

Problem

The SDK's money-safety story leans on Pydantic v2 features that landed or stabilized after 2.0: StrictInt boolean-rejection behavior was tightened in 2.4 (the #295 fence relies on it), model_validator(mode='before') inheritance semantics changed through 2.3, and several Decimal coercion edge cases (negative-zero, scientific input) were fixed in 2.4/2.5. Allowing 2.0–2.3 means a pip resolver can land a runtime with subtler validators than the test matrix exercises, quietly undermining #225 / #243 / #295.

The SDK itself has no vulnerability here; the floor is inconsistent with the invariants the changelog advertises.

Evidence

• pyproject.toml:24:

"pydantic>=2.0,<3",

• CHANGELOG.md v2.6 bug: int-typed request fields silently coerce bool (subaccount routing, transfers, counts) #295 explicitly relies on StrictInt bool rejection; v2.5 Polish bundle: model small items (AwareDatetime in WS, V1 Literal, default=None, timestamp typing, Decimal NaN) #270 relies on _coerce_decimal is_finite() behavior that interacts with negative-zero / scientific-input handling fixed across 2.4/2.5.

Suggested fix

Raise the floor to pydantic>=2.5,<3 (matches the version Python 3.12 wheel + StrictInt semantics tested in the project). If 2.4 testing exists, pydantic>=2.4,<3 is also defensible, but 2.0–2.3 should be dropped. Verify the bump against the existing test suite under the minimum version.

Source

Round-3 independent audit (reviewer: security_auth).