Cache integer/decimal token sets in ConstrainedJSONGenerator (like the string set already is)

[oscarbc96]

Problem

ConstrainedJSONGenerator.init unconditionally calls buildValidIntegerTokens
and buildValidDecimalTokens on every construction (Sources/AnyLanguageModel/Shared/StructuredGeneration.swift:110-111).
Each does a full 0 ..< backend.vocabSize scan and, per token, calls
backend.isSpecialToken(token) and backend.tokenText(token). On the MLX
backend, isSpecialToken calls tokenizer.decode(tokens:skipSpecialTokens:)
twice and tokenText calls it once more — three tokenizer decode calls per
vocab entry.

On a 151,936-token vocabulary (Qwen3-1.7B), that's ~456K decode calls per
scan, ~911K for the pair, on every single ConstrainedJSONGenerator
construction — regardless of whether the schema being constrained contains
any numeric field at all (the scan isn't gated on schema content).

buildValidStringTokens already solves this exact problem: it's memoized in
StringTokenCache, keyed by tokenizer identity (vocabSize/eosToken/endTokens/sampleTexts).
The integer and decimal scans had no such cache.

Fix

Mirror the existing StringTokenCache pattern for the integer and decimal
scans: two new sibling Locked<[Key: Set<Int>]> dictionaries, with a
guard-and-store block around each build function. No other behavior change.

Measured (Qwen3-1.7B-4bit/MLX, Apple Silicon, M-series)

• Each scan: 1.8–1.9s cold → 44µs/17µs on cache hit (five to six orders of
  magnitude).
• End-to-end constrained generation (one call = one ConstrainedJSONGenerator
  construction): 9.9–12.3s → 6.2–8.6s, a ~30–40% reduction in the warm decode
  floor.
• Output verified unchanged: cached token sets are byte-identical to their
  uncached computation, so this cannot itself introduce nondeterminism.

Testing

git apply --check verified clean against 0.8.0 (163f385). Manual
instrumentation (temporary ContinuousClock prints, not part of this diff)
confirmed cache hits on the second call within the same process. No existing
test coverage exercises ConstrainedJSONGenerator timing directly, so this
is a pure perf fix with no behavior change to verify against.