fix: honor imported overrides of core built-ins

[fglock]

Failure

File::chmod 0.42 fails under PerlOnJava in CPAN run 20260827-102602-1611: 9 of 39 subtests fail across symbolic read, write, executable, sticky-bit, and permission-removal cases.

The module is pure Perl. Its exported chmod subroutine accepts symbolic modes such as +r and converts them to numeric modes before calling CORE::chmod.

PerlOnJava instead compiles an imported bare chmod call as the core numeric opcode. It warns that symbolic values are non-numeric and leaves the mode unchanged.

Minimal reproduction

use File::chmod;
use File::Temp qw(tempfile);

my ($fh, $path) = tempfile();
close $fh;
chmod('+r', $path) or die "chmod: $!";
printf "%04o\n", (stat($path))[2] & 07777;

System Perl prints 0644 (with the module's documented default umask behavior). Both PerlOnJava backends print 0000.

The qualified control works in both PerlOnJava backends:

File::chmod::chmod('+r', $path);

That call prints 0644, confirming that the module implementation and filesystem operation are functional. The defect is resolution/compilation of an imported subroutine whose name matches a core built-in.

Baseline

The upstream File::chmod 0.42 suite passes completely under system Perl: 19 files and 39 tests, with Result: PASS.

Expected behavior

After use File::chmod, an unqualified chmod(...) must dispatch to File::chmod::chmod, as it does in Perl. CORE::chmod(...) must continue to select the core opcode explicitly.

[fglock]

Follow-up CPAN verification coverage: LockFile::Simple 0.208 failed in CPAN
run 20260827-102606-1637 for the same imported-core-builtin resolution
defect.

The distribution is pure Perl, and its complete upstream suite passes under
system Perl (13 tests across t/basic.t, t/simple.t, and t/user.t).

t/basic.t imports lock, trylock, and unlock:

use LockFile::Simple qw(lock trylock unlock);

On both PerlOnJava backends, the unqualified lock('t') dispatches to the
core lock operator rather than the imported LockFile::Simple::lock
subroutine. It returns the argument string and creates no t.lock, causing
the subsequent -r and trylock assertions to fail. The qualified control
works on both backends:

LockFile::Simple::lock('t')

It returns the expected LockFile::Lock::Simple object and creates the lock
file, confirming that the module implementation is otherwise functional.

After fixing this issue, run the complete LockFile::Simple 0.208 suite as
regression coverage. Its final t/simple.t autoclean assertion still requires
fork and remains outside this issue's scope because PerlOnJava does not
implement process forking.