Cover the decimal operand grammar in the conformance corpus

[kikashy]

Goal

Add cases for the decimal-string grammar that ordered fact comparisons require.

Why

Core §2.2 fixes the operand form for greater-than, greater-than-or-equal, less-than and less-than-or-equal:

decimal = [ "-" ] ( "0" / non-zero-digit *DIGIT ) [ "." 1*DIGIT ]

That grammar exists because JSON numbers are the wrong carrier for a quantity whose exact decimal identity matters — a threshold that silently becomes a float is the failure it prevents.

The grammar refuses a leading +, leading zeros, a bare .5, a trailing 5., exponent notation, and surrounding whitespace. It accepts -0.5, 0.10, and a long fractional part. The corpus does not walk those edges, so an implementation could accept 1e3 as an operand and still pass.

Scope

• Add cases under conformance/semantic/ for at least: leading +, a leading zero such as 007, bare .5, trailing 5., an exponent form, an operand with surrounding whitespace, and an empty operand — each expected invalid.
• Add at least two accepted operands that look unusual but conform, such as -0.5 and 0.10.
• Add matching manifest entries with the diagnostic code and path the repository's validator produces.
• Update the corpus count statements; a harness test derives them.
• Do not change the schema, the grammar, the validator, or normative text.

Acceptance criteria

• Each rejected form above has a case, and at least two accepted forms are present.
• Accepted cases include one whose decimal identity would change if parsed as a float.
• Diagnostics match what the validator reports; run the suite rather than guessing.
• python -m unittest discover -s tests -v passes.
• Every commit is signed off (git commit -s).

Contributor learning

Why a specification carries its own decimal grammar instead of deferring to JSON numbers, and how to probe a grammar at its edges.