Fix Perl-compatible scalar filehandle and truncate failure semantics

Start by reproducing the six failures in t/recordstore.t on both the JVM and interpreter backends, then trace the shared runtime paths for scalar filehandles and truncate. Done means Perl-compatible undefined and failure values, correct error propagation, passing t/recordstore.t on both backends, and green filehandle, chmod, truncate, and error-propagation tests.

Data::RecordStore exposes two PerlOnJava I/O semantic differences

Summary

The CPAN compatibility run for Data::RecordStore v5.03 reports 6 failures in t/recordstore.t. The complete upstream suite passes under system Perl, while both the JVM backend and the interpreter backend reproduce the same failures.

CPAN run: 20260916-111623-23683

Results

• System Perl: 1,339/1,339 tests pass.
• PerlOnJava JVM backend: 6/328 assertions fail in t/recordstore.t; the other three test programs pass.
• PerlOnJava interpreter backend: the same 6 assertions fail.
• The failure is not a dependency or native-code problem; Data::RecordStore is pure Perl.

The six failures are two behaviors repeated once for each store mode:

1. t/recordstore.t expects a localized scalar filehandle opened with
   open STDERR, ">>", \$out to leave $out undefined when nothing is
   written. PerlOnJava initializes it to a defined empty string instead.
2. The test changes a record file to mode 0444 and calls the module’s
   empty method. The implementation uses
   truncate($first, 0) // die "Unable to empty silo ...". Under system
   Perl, truncate returns undef with a permission error and the expected
   exception is raised. Under PerlOnJava, truncate returns a defined false
   value with a Truncate failed: ... error, so the defined-or die path is
   skipped and the test incorrectly sees the operation as successful.

Minimal behavior comparison:

system Perl:       scalar STDERR target remains undef
PerlOnJava:        scalar STDERR target becomes defined ""

system Perl:       truncate(0444-file, 0) returns undef
PerlOnJava:        truncate(0444-file, 0) returns defined false

Both PerlOnJava backends show the same results, so this is shared runtime I/O behavior rather than a backend-specific compiler issue.

Impact and priority

MetaCPAN reports 2 released runtime dependants of Data::RecordStore:
Data::ObjectStore and Yote. Neither has released within the last three
years. This distribution-level footprint does not support the high-impact
label, although the underlying scalar-filehandle and file-operation semantics
may affect other Perl code beyond this CPAN consumer.

Suggested acceptance criteria

• A localized scalar filehandle opened for append preserves Perl’s undefined
  value until data is written.
• Failed truncate operations return Perl-compatible failure values and set
  the appropriate error state so // die error paths execute.
• Data::RecordStore t/recordstore.t passes on both JVM and interpreter
  backends.
• Existing filehandle, chmod, truncate, and error-propagation tests remain
  green.