The corpus DECIMAL parser #761 added cannot be reached, and the README says BYTES is still reserved

[tamnd]

#761 added a DECIMAL parser to the corpus reader and left the reservation that stops anything from calling it, so the arm is dead code. The same edit was not made in the C runner, and the README paragraph that describes the reservation is stale for the other name in it.

The parser is unreachable

crates/zu-corpus/src/value.rs:438 gained

"DECIMAL" => decimal(text),

and a decimal helper below it that refuses an exponent and takes the scale off the fraction's length. Neither runs. TYPES at line 150 has no DECIMAL entry, so form() at line 187 answers None, and a value is refused before scalar is called. What refuses it is unknown() at line 193, which reads RESERVED at line 185:

const RESERVED: [&str; 1] = ["DECIMAL"];

The test at line 761 pins that behaviour:

let err = read("type: DECIMAL\nvalue: \"1.00\"\n").expect_err("refused");
assert!(err.contains("reserves"), "{err}");

So the engine has a decimal value, the corpus reader has a decimal parser, and a case that writes one is still refused with a message saying the engine has no value for it. That message is now wrong on its own terms.

This is the same shape #569 fixed for BYTES: the type became real and the reservation had to come off with it.

The C runner was not touched

conformance/c/value.c:851 still reads

static const char *const RESERVED[1] = {"DECIMAL"};

with no parser beside it. The two implementations are supposed to be the same encoding down to which spellings are refused, and CI diffs their reports line for line, so whichever way this goes both have to move together. Un-reserving in Rust alone would be a case the reference reads and the C runner refuses, which is a cross-client diff rather than a passing suite.

The README is stale for BYTES

conformance/README.md:251:

DECIMAL and BYTES are reserved: the names are refused today rather than silently accepted as unknown, so that the first case to need one is a decision somebody makes rather than a spelling that happened to parse.

BYTES has not been reserved since #569. It is in TYPES at crates/zu-corpus/src/value.rs:164 as Form::Text and has a parser at line 415. A reader following that paragraph would write a BYTES case expecting it to be refused, or avoid writing one that would work.

What a client sees

zu-go carries the same reservation, because a client that read a case the reference refuses would be the one reporting a difference. It renders a decimal in a failure report, since CAST('1.20' AS DECIMAL(5, 2)) reaches one and a report that cannot print what it got is the least useful moment to find out, but it will not read type: DECIMAL from a case until this does. The other clients are in the same position. Whichever way it lands, one line here decides it for all nine, which is the argument for deciding it rather than leaving the parser sitting behind the reservation.

Two asks

1. Either finish An exact decimal is an integer and a scale #761's half by giving DECIMAL a TYPES entry in both runners, turning the test at line 761 around, and saying in the README that it is a type now, or take the unreachable parser out so the reservation is the whole story. The first looks right, since a decimal is a value the engine hands back today and no case can assert one.
2. Fix the README line for BYTES either way.