Summary

The char scanner accepted any byte value for \\xNN (0x00..0xFF), but raw non-ASCII bytes were rejected at the same site. The asymmetry let sources build with \\xFF and fail only when the user typed the byte directly.

This PR matches the raw-byte restriction in the \\x branch: parse the two hex digits, then fail with the existing "character literal must be one byte" diagnostic if the value is >= 0x80. \\x00..\\x7F still decode to those bytes; the char scanner's \\0 escape continues to map to NUL, so users can produce a NUL char either way.

Closes one item from #318 (audit finding B6, re-confirmed against main).

Test plan

conformance/native/fail/char-hex-7f.0 covers \\x80 (the first rejected value)
conformance/native/fail/char-hex-high.0 covers \\xFF
pnpm run conformance passes
compiler-metrics.mts has 0 violations (budget bumped by 12)
No C compiler warnings (verified with -Wall -Wextra -Wpedantic)