Preserve leading zeroes when autoincrementing zero-padded strings

[fglock]

Summary

Time::Normalize v0.09 exposes a PerlOnJava string autoincrement
compatibility bug. PerlOnJava removes leading zeroes when incrementing a
zero-padded numeric string, while standard Perl preserves the padding through
the string-increment sequence.

CPAN evidence

• Distribution: Time::Normalize 0.09
• CPAN run: 20260910-101908-8428
• Failure record: FAIL Time::Normalize Time::Normalize
• Failing test: t/month.t, 48 assertions
• PerlOnJava result: 574/622 assertions pass
• System Perl result: the complete upstream suite passes, 622/622
• Environment: pure-Perl distribution with no native, display, network, or
  platform prerequisite

The failures are reproducible on both the JVM and interpreter backends.

Minimal reproducer

my $expected = '01';
for (1 .. 12) {
    print "$expected\\n";
    ++$expected;
}

Expected under standard Perl:

01
02
03
04
05
06
07
08
09
10
11
12

Observed on PerlOnJava:

01
2
3
4
5
6
7
8
9
10
11
12

CPAN failure details

Time::Normalize::normalize_month returns the correct values (01 through
12) for the locale's full and abbreviated month names. The failure is in the
test's expected-value counter, which starts at the string 01 and increments
it after each assertion. Standard Perl keeps the leading zero for 02 through
09; PerlOnJava does not. Consequently, the February-through-September
checks fail for full names, uppercase names, lowercase names, abbreviations,
and their case variants. Numeric and other date/time tests pass.

Locale handling was also compared directly: both system Perl and PerlOnJava
produce the same English month and abbreviation names under the test locale.

Root cause

PerlOnJava's string autoincrement implementation treats a string beginning
with digits as an ordinary numeric value and stores the incremented result as
an unpadded integer. Perl's magical string increment preserves the width of a
zero-padded decimal sequence until the sequence reaches a wider width.

This is a shared runtime behavior affecting both execution backends, not a
bug in Time::Normalize or the test's locale assumptions.

Expected fix

Implement Perl-compatible handling for zero-padded decimal strings in string
autoincrement, including preservation of the original width for values such
as 01 through 09. Retain existing behavior for ordinary numeric values,
alphabetic magical strings, and carry transitions.

Add permanent project-owned regression coverage for the sequence above and
validate it with system Perl, the JVM backend, and the interpreter backend.

Related issue search

No existing repository issue was found covering this exact leading-zero
string-autoincrement behavior. The report is filed separately from unrelated
numeric scalar-typing issues because this failure is specifically caused by
the ++ string representation rule.