[Bug]: IntegerSequenceRequest has no per-item digit bound

[morluto]

Summary

IntegerSequenceRequest.values is bounded to max_length=256 items, but CanonicalInteger has only a pattern constraint with no digit-count limit. Every sequence operation calls parse_canonical_integer on each value, so previously guarded oversized operands are now reachable by every sequence operation without a domain-level bound.

Evidence

src/jacobian/contracts/sequences.py L13-19:

class IntegerSequenceRequest(ContractModel):
    """One nonempty finite sequence of canonical integers."""

    values: tuple[CanonicalInteger, ...] = Field(
        min_length=1,
        max_length=_MAX_SEQUENCE_LENGTH,
    )

CanonicalInteger (src/jacobian/contracts/exact.py L13-18) has only pattern=r"^(?:0|-?[1-9][0-9]*)$" with no digit-count limit. Other domain contracts (e.g., CanonicalRational at exact.py L78-81) enforce MAX_CANONICAL_RATIONAL_DIGITS, but IntegerSequenceRequest has no equivalent.

Root cause

The sequence contract bounds item count but not item magnitude.

Scope

Add a max_digits field-level validator to IntegerSequenceRequest.values or a cross-field model_validator that rejects items exceeding a domain-defined digit bound.

Source

• refactor(math): use canonical integer conversions #807 (comment)

Generated with Devin

[morluto]

Confirmed on current main and triaged under the aggregate-cost owner #1036. The request currently bounds sequence length but not operation-relevant total digits/bits. The fix should be a documented sequence-domain magnitude policy plus aggregate preflight—not necessarily one identical per-item cap for every sequence operation, since sort/frequency/product/recurrence costs differ.