printf refuses an operand it cannot read as a number

[tobert]

AGENTS.md names printf '%d' 0xff printing 0 as the shape to refuse, and printf was printing it. The conversions read a value through s.parse().unwrap_or(0) and *f as i64, so 0xff, abc and 1e3 all answered 0, 1.5 answered 1, and %c of 4294967296 truncated through as u32 into NUL. 007 was the worst of them: it answered 7, a plausible number, while every other number position in kaish had just been taught that a leading zero is text.

printf now reads a number by JSON's rules, the same ones fromjson uses, so the answer does not depend on which builtin is asking. Each refusal names the spelling that works:

printf '%d' 0xff   → printf: `0xff` is not a number; write `255`, or `$(( 0xff ))` to read the base
printf '%d' -007   → printf: `-007` has a leading zero — kaish reads no octal; write `-8#7` for octal or `-7` for decimal
printf '%d' 0b101  → printf: `0b101` is not a kaish base spelling; write `2#101` for binary
printf '%d' 1e3    → 1000

A MISSING operand still converts as 0, which POSIX requires and which is not the fallback being removed; only a value that is present and unreadable refuses, and it refuses before any output so a caller never reads a half-written line as a whole answer.

The seam worth knowing about is FormatArg, which printf and awk share. They disagree here on purpose: in POSIX awk a non-numeric string IS 0, and that is awk being correct, not awk being unfixed. The trait's numeric conversions became fallible so each caller answers for itself — awk's impl is always Ok. Two tests pin awk's coercion as the control that the refusal did not leak across the trait.

A review of the first pass found the refusal had left one silent answer standing. printf '%d' '-9223372036854775809' printed -9223372036854775808 and exited 0: not an i64, so it fell to the JSON reader, which read it as f64, where it rounds to exactly i64::MIN, which the range guard then accepted — correctly, because i64::MIN is in range. Every step was locally right and the answer was wrong by one. printf now uses the same is_i64_overflow_shape guard value_to_num already had, refusing an integer-shaped operand before a float can round it.

That review also corrected four messages that named the wrong fix or none (+007 dodged the leading-zero rule entirely and answered 7), and two tests that were passing through the wrong code path. Nothing in the existing suite changed behavior: 6485 → 6514 tests, all additions.

This diverges from GNU for 0xff, which GNU reads as 255 — deliberate, and the same divergence $(( )) already documents. For abc GNU also errors.

Gates: clippy -D warnings, cargo test --all (204 suites, 6514 passed, 0 failed), insta --check, no-default-features, the WASI build, and rustdoc -D warnings all clean.