test(json-pointer): add boundary, escape, and normalization coverage

[vtushar06]

I walked the RFC 6901 section 3 grammar against the current optional/format/json-pointer.json (40 tests) and found seven distinct cases the suite does not have anywhere, each of which can catch a wrong implementation the existing tests let through. All seven are handled correctly by ajv-formats 3.0.1 (full and fast) and python-jsonschema 4.25.1, so they do not break the dominant validators - they close real gaps.

Changes

Seven tests added to tests/*/optional/format/json-pointer.json (draft6, draft7, draft2019-09, draft2020-12). Control, DEL, and fullwidth characters are stored as \uXXXX escapes, the same way the existing NUL/LF/TAB test does.

Character-class boundaries (a hand-rolled unescaped character class with an off-by-one flips these):

• /01 (valid) - a leading-zero index-looking token is a valid string. The leading-zero ban in section 4 is about resolving an array-index, not section-3 string validity. The suite has /foo/0 but no multi-digit leading-zero token.
• /\u007f (valid) - DEL, the first code point of the third range %x7F-10FFFF. The suite covers %x00-1F and an astral char, but nothing pins the %x7E(~)/%x7F boundary.
• /} (valid) - } is %x7D, the top of the middle range %x30-7D, one code point below the excluded ~ (%x7E). The suite has | (%x7C, in /g|h) but not }, so a class written [\x30-\x7C ...] ships the off-by-one silently.

Escape and NUL handling:

• /foo\u0000~ (invalid) - a dangling ~ after an embedded NUL. An implementation that copies the string into a null-terminated buffer truncates at the NUL, sees /foo, and wrongly accepts. The existing NUL test is valid data, so a truncating implementation passes it.
• /~０ (invalid) - a ~ followed by a fullwidth digit zero U+FF10. A ~ must be followed by ASCII 0/1; a validator that completes the escape with a Unicode-aware digit test (\d with the Unicode flag, Character.isDigit, ...) wrongly accepts it. /~2 does not catch this - an ASCII [01] check correctly rejects /~2 yet can still accept /~０.

Normalization resistance (section 3 does no normalization):

• /～ (valid) - a fullwidth tilde U+FF5E is an ordinary token char, not the escape introducer ~. A validator that applies NFKC before checking folds it to ~ and wrongly rejects it as a dangling escape.

Alternate representation:

• #/foo (invalid) - the section 6 URI-fragment form with a real pointer tail. The suite has #, #/, #a, but a validator that strips a leading # and validates the rest passes all three (it rejects a bare #) while accepting #/foo. Newtonsoft.Json.Schema 4.0.2 does exactly this.

RFC References

• RFC 6901 section 3 - the string grammar
• RFC 6901 section 4 - the array-index leading-zero rule is resolution, not string validity
• RFC 6901 section 6 - the #-fragment form is a separate representation

I left out //, ///, and ~01 on purpose - PR #877 already declined those as redundant.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vtushar06]

hey @jviotti please have a look at this whenever you have timewidth.

[jviotti]

Looks like good extra coverage to me

[jdesrosiers]

The v1 tests are out of sync with the other branches.

[vtushar06]

@jdesrosiers i think you are very right on this all five files now hold the same 46 tests and differ only in $schema.

[vtushar06]

ready for final look.