fix: support Tie::File::Indexed file-backed arrays

[fglock]

Failure

Tie::File::Indexed 0.09 fails under PerlOnJava in CPAN run 20260827-102606-1637.

The distribution is pure Perl and configures and builds successfully. Its test suite then reports 21 failed subtests out of 94 in the JVM backend:

• t/02_basic.t: 12/58 failures, including assign: content, append: push, append: content, consolidate, copy: file, rename: content, move: content, and reopen/rw: content.
• t/03_utf8.t: 2/4 failures.
• t/04_json.t: 2/5 failures.
• t/05_storable.t: 5/20 failures.

The common symptom is that indexed-file writes appear successful, but later reads report an empty index or missing content. File-size checks after consolidation/pop are also incorrect.

Baseline

The same upstream release passes its complete suite under system Perl:

Files=5, Tests=94
Result: PASS

Backend coverage

• JVM backend: reproduces the upstream failure summary above.
• Interpreter backend: the initial assignment fails, then execution aborts while handling the tied array with Can't locate object method "size" via package "Tie::File::Indexed" at Tie/File/Indexed.pm line 779.

Reproduction

Obtain Tie-File-Indexed-0.09, build it with its normal Makefile.PL, then run its upstream tests with PerlOnJava:

timeout 120 /path/to/jperl -Iblib/lib t/02_basic.t
timeout 120 /path/to/jperl --interpreter -Iblib/lib t/02_basic.t

The JVM failure also occurs in the full make test suite. Investigation should focus on the interaction of tied-array indexed storage with filehandle seek/tell/read/write/reopen operations.

[fglock]

Root cause identified: PerlOnJava incorrectly invalidates an earlier parsimonious filehandle alias created with open $fh, "+>&=", fileno($sysfh) when a later alias is opened.

Tie::File::Indexed opens its index file and then its data file using this idiom. The index handle is the first alias, so its STORE calls can write the data file but cannot write/read the index: immediately after each store, tell($obj->{idxfh}) returns -1 and $! is Input/output error; the data handle's position advances normally. All later missing-content failures follow from the unusable index.

Minimal reproducer:

use Fcntl qw(:DEFAULT :seek);
use File::Temp qw(tempfile);

my ($x, $a) = tempfile();
my ($y, $b) = tempfile();
close $x; close $y;

sub open_alias {
    my ($file) = @_;
    sysopen(my $sysfh, $file, O_RDWR | O_CREAT | O_TRUNC, 0666) or die $!;
    open(my $fh, '+>&=', fileno($sysfh)) or die $!;
    return $fh;
}

my $first  = open_alias($a);
my $second = open_alias($b);
print {$first}  'a' or warn "first-print: $!\n";
print {$second} 'b' or warn "second-print: $!\n";
seek($first,  0, SEEK_END) or warn "first-seek: $!\n";
seek($second, 0, SEEK_END) or warn "second-seek: $!\n";
print "first=", tell($first), " second=", tell($second), "\n";

System Perl prints first=1 second=1. Both PerlOnJava backends make the first alias unusable (first=-1, with an I/O error) while the second remains valid.

The likely implementation fault is the &= borrowed-handle path in IOOperator.openFileHandleDup / BorrowedIOHandle: it does not preserve the source sysopen handle's lifetime or descriptor registration independently for multiple aliases. The fix should retain the shared underlying resource until every relevant handle is closed, while preserving Perl's &= alias semantics.