fix(printf): cap float exponent magnitude in format validation

[chaliy]

Motivation

• The generated uucore-backed printf path can parse floats into arbitrary-precision BigDecimal and then materialize a fixed-decimal String, letting tiny inputs like 1e1000000000 cause enormous allocations because preflight validation only checked width/precision.
• Prevent untrusted script input from forcing massive intermediate allocation before interpreter stdout truncation by failing early during format-cap validation.

Description

• Extend CapSpec with a specifier field and detect float-style specifiers via is_float_specifier to run float-specific checks while keeping existing width/precision caps.
• Implement reject_float_exponent_over_cap which peeks the raw argument, uses parse_float_exponent + parse_leading_i64 to extract an exponent, and rejects it if its magnitude exceeds MAX_FORMAT_WIDTH.
• For float specifiers the validator now checks exponent magnitude instead of blindly consuming the argument; non-float specs retain prior args.consume behaviour.
• Add unit test rejects_float_exponent_over_cap asserting render_printf("%f", &["1e1000000000".into()]) fails quickly with a cap error.

Testing

• Ran cargo test -p bashkit rejects_float_exponent_over_cap -- --nocapture and the new test passed (ok).
• The crate compiled and the affected unit tests executed with no failures observed for the modified code paths.

---

Codex Task

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	275bebd	Commit Preview URL	May 09 2026, 12:26 AM