JVM backend loses IO::Handle input_line_number #1933

Summary

The JVM backend cleared $. when a temporary borrowed alias of an anonymous filehandle left a subroutine scope, even though the caller still owned the live IO glob. A subsequent IO::Handle->input_line_number therefore returned undef. Pod::Eventual propagated that value as start_line => undef, causing Pod::Elemental's Int constraint to fail.

Reproduction

use IO::Handle;
my $text = "one\ntwo\n";
open my $fh, "<", \$text or die $!;
$fh->getline;
print defined($fh->input_line_number) ? $fh->input_line_number : "undef", "\n";

On the reported JVM run the result was undefined; interpreter and system Perl return 1.

Evidence

• CPAN distribution: Pod::Elemental::Transformer::List 0.102001
• Run: 20261030-095654-34969
• Failing test: t/equiv-pods.t; original JVM run failed 1/3 test programs, with 0/4 subtests reached in the failing program.
• System Perl oracle: all 3 files and 16 tests passed.
• The focused regression fails on the unfixed origin/master baseline and passes on the fix under system Perl, JVM, and interpreter.
• After the fix, all three distribution test files and all 16 tests pass under both PerlOnJava backends with the archived CPAN dependency load order.

The fix preserves last-read-handle context when an anonymous IO alias is borrowed and a live owner remains. Scope cleanup still clears the context when the actual owner leaves.