Investigate JSONY null values becoming stale numbers

[fglock]

Summary

The CPAN compatibility run identified a JSONY 0.1.21 regression in PerlOnJava. The upstream test suite passes under system Perl, but the archived PerlOnJava run produced numeric values where JSON/YAML null values were expected.

Evidence

• CPAN run: 20260902-193404-39801
• Baseline commit recorded by the regression report: ff68371af
• Distribution: JSONY 0.1.21
• Failed tests: t/testml-json.t and t/testml-load.t
• Result: 15/51 subtests failed; 2/7 test programs failed
• System Perl: the focused JSONY suite passed completely (44/44 tests)
• Current PerlOnJava: the focused suite passes under both the JVM and interpreter backends

Representative archived mismatches included:

expected: - null
actual:   + 1

expected: port: null
actual:   port: 8080

expected: width: null / height: null
actual:   width: 250 / height: 250

The values are not consistently converted to zero or another fixed sentinel; they appear to be values from nearby/current parser data. This suggests corruption or reuse of a scalar temporary, callback argument, or alias rather than a JSONY semantic error.

Suspected ownership

JSONY's JSONY::Receiver::got_bare recognizes null before the numeric pattern and returns Perl undef:

/^null$/ ? undef :
/number-pattern/ ? ($_ + 0) :
"$_"

It also unpacks the callback arguments with (undef, $_) = @_. Investigate whether PerlOnJava preserves the callback argument and the returned undef independently when compiling/executing this code. A regex-engine defect is possible only indirectly (for example, if the grammar supplies the wrong token), but the numeric pattern cannot match the literal string null, so the archived evidence more strongly suggests scalar/alias/temporary handling around the callback.

Requested investigation

1. Add a minimal project-owned regression test for repeated got_bare('null') calls interleaved with numeric tokens and for the corresponding JSONY load path.
2. Run the reproducer on system Perl, JVM PerlOnJava, and interpreter PerlOnJava.
3. Inspect the value before the regex dispatch and immediately after the null branch to distinguish grammar/tokenization, regex matching, callback argument aliasing, and stale temporary/register reuse.
4. If the defect is already fixed, identify the fixing commit and retain the focused regression coverage.

This issue is based on a historical CPAN regression; current PerlOnJava passes the focused tests, so the first step should be confirmation and regression-test preservation rather than assuming the bug remains open.