v0.2.1: fix C UB on admitted 1e20-class inputs; sanitizer CI gate; hardening

[SaMullinsJr]

Corrective release candidate for the C-lineage undefined behavior found in the 2026-07-15 external security review. v0.2.0 stays published; this supersedes it.

The defect

c/src/canonical_json.c write_number evaluated (double)(long long)d before its fabs(d) < 1e15 range guard. For integer-valued fraction tokens ≥ 2⁶³ inside the supported domain (e.g. {"x":100000000000000000000.0}, |v| < 10²¹) the conversion is undefined behavior (C11 §6.3.1.4p1) — reproduced under UBSan through the real CLI. No known wrong hash was produced (on x86-64 the conversion saturates and falls through to the correct big-integer branch; 7/7 agreement on the affected class verified before and after), but UB is not a cross-platform contract.

Changes

• Fix: guard precedes any conversion — fabs(d) < 1e15 && trunc(d) == d — same order the C++ lineage already used
• Regression vector: huge_integer_valued_float pinned in the corpus (25 accept + 31 reject, 7/7 green)
• Sanitizer CI: new sanitize job — C and C++ under -fsanitize=address,undefined,float-cast-overflow -fno-sanitize-recover=all, unit tests + full corpus through the instrumented CLIs via new conformance/run_corpus_cli.py (reject = clean nonzero exit; sanitizer abort = crash, not a rejection)
• C allocation hardening: strbuf OOM latch, checked malloc/realloc (no live-pointer overwrite), size_t-overflow-guarded growth; baion_canonicalize_json returns NULL on failure — never a partial canonical string
• Supply chain: permissions: contents: read; job timeouts; cJSON pinned to commit acc76239 (v1.7.18); exact toolchain pins (Rust 1.94.0, DMD 2.112.0, GHC 9.6.7, cabal 3.16.1.0, opam package pins); Cargo.lock and cabal.project.freeze committed
• CHANGELOG.md added; versions bumped to 0.2.1

Deliberately deferred (documented in CHANGELOG)

Resource limits (input size, nesting depth, member counts): a limit changes which documents are rejected, so it is a cross-lineage contract change — all seven lineages must adopt identical limits in one release or uniform rejection breaks. Same for the O(n²) duplicate-key scan cap and the C-locale assumption.

Local receipts at this RC

• Before fix: canonical_json.c:189:5: runtime error: 1e+20 is outside the range of representable values of type 'long long int' (UBSan, real CLI, in-domain input)
• After fix: same sanitized build + input → 356acd21…, exit 0
• verify_all_lineages.sh PASS 7/7 · differential_probe.py 234 cases 0 divergent · fuzz_agreement.py seed=20260715, 8000 cases, 0 failures
• Sanitize job steps run locally for both lineages: corpus green under ASan+UBSan

Review questions

1. Any other conversion in any lineage with the same guard-order defect?
2. Is the OOM/NULL contract sound — any path that can still hash a partial canonical string?
3. Is the sanitize CI job correctly constructed?
4. Any objection to the deferred-scope reasoning?

🤖 Generated with Claude Code