Fix #1557: eagerly validate separator after non-root number values

[seonwooj0810]

Fixes #1557

Problem

Number values inside Arrays / Objects (non-root) were not checked for a
valid trailing separator. Only root-level values were validated (added in #105,
extended in #679 for the second-decimal-point case). For non-root numbers the
parser simply pushed the trailing character back and returned the number token,
so malformed content failed lazily — only when the next token was read:

// all of these reported a number token first, failing one token too late:
[ 123true ]   // -> 123
[ 100k ]      // -> 100
[ 100/ ]      // -> 100
[ 1.5x ]      // -> 1.5
[ 1.5false ]  // -> 1.5

Approach

Generalize the existing root-only _verifyRootSpace into a
_verifyNumberSeparator helper, called at every number-completion site in the
three blocking parsers (ReaderBasedJsonParser, UTF8StreamJsonParser,
UTF8DataInputJsonParser). Root values keep the exact previous behavior; a
non-root number must now be followed by one of:

• white space (' ', '\t', '\n', '\r')
• a value separator / structure end: , ] }
• a comment start / or # when the corresponding JsonReadFeature is enabled
• end-of-input

otherwise an expected space, comma, or closing bracket/brace ... error is
reported at the offending character (location aligned with the root path).

Performance: the check reuses the trailing character that the number loop
already reads to detect end-of-number (no extra buffer access / look-ahead),
and the accept/reject decision is a constant-time switch. The hot path cost is
therefore negligible, and the change keeps the same performance shape as the
existing _verifyRootSpace it generalizes.

Scope / follow-up

This PR covers the three blocking parsers. The async (non-blocking)
parser still fails lazily for this case — its number state machine completes at
several different points (including buffer-boundary resumption) and deserves a
separate, carefully-tested change. Its reproduction remains under
tofix/async/AsyncTokenBranchNumberErrorTest with @JacksonTestFailureExpected.

@cowtowncoder — do you want async handled in this PR, or as a separate follow-up?
Happy to extend if preferred.

Tests

• Added nonRootMangledIntegers1557 / nonRootMangledFloats1557 to
  NonStandardNumberParsingTest (verified across ALL_MODES).
• Added nonRootNumberFollowedByComment1557 to prove the / and # branches:
  numbers immediately adjacent to comments ([1/* c */,2], [1// c\n,2],
  [1#c\n,2]) still parse when comments are enabled.
• Removed the now-fixed tofix repros for the blocking parsers (assertions moved
  into the suite above), mirroring how Number parsing should fail for trailing dot (period) #679 was handled.

Full ./mvnw clean test is green.

[github-actions]

📈 Overall Code Coverage

Metric	Coverage	Change
Instructions	83.01%	📈 +0.000%
Branches	75.77%	📈 +0.050%

Overall project coverage from JaCoCo test results. Change values compare against the latest base branch build.