Match standard Perl defer ordering and caller semantics

Start with the failing assertions in the upstream Feature::Compat::Defer test t/01defer.t, then trace how defer blocks are represented, scheduled at scope exit, and exposed through caller. Reproduce the ordering and caller cases on both JVM and interpreter backends, and add project regressions covering the listed control-flow cases; done means all focused regressions and all 30 upstream tests pass.

Summary

PerlOnJava does not fully reproduce standard Perl behavior for the core feature 'defer' construct used by Feature::Compat::Defer 0.02. The unchanged upstream suite passes under system Perl, but PerlOnJava fails deferred-block ordering around continue and exposes an extra caller frame for deferred blocks.

CPAN evidence

CPAN random tester run 20260915-094334-6702:

• Distribution: Feature-Compat-Defer 0.02
• System Perl: 30/30 tests pass across 4 test programs
• PerlOnJava: 28/30 tests pass; 2 assertions fail in t/01defer.t
• Build and test setup complete successfully
• The archived target run uses the default JVM backend

The failing assertions are:

defer + continue happens in an order
  got:      d1c1d2c2
  expected: c1d1c2d2

caller does not see defer as __ANON__
  got:      main:t/01defer.t:228:main:t/01defer.t:232
  expected: main:t/01defer.t:232

The other Feature::Compat::Defer tests pass, including module loading, exception behavior, and POD validation.

Failure 1: deferred-block ordering around continue

The test exercises a loop with deferred actions and continue. Standard Perl runs the loop continuation before executing the deferred actions for the relevant scope, producing c1d1c2d2. PerlOnJava produces d1c1d2c2, executing each deferred action before its corresponding continue path.

The fix must preserve defer ordering across loop bodies, continue blocks, nested scopes, early exits, and exceptions. It should not be implemented as a distribution-specific rewrite.

Failure 2: caller frame visibility

The test checks that code called from a deferred block sees the same caller context expected by standard Perl. PerlOnJava exposes an extra anonymous frame corresponding to the implementation of the deferred block.

The fix must preserve Perl-compatible caller results while still allowing deferred blocks to execute after the surrounding scope has completed. It should account for nested calls, eval, recursion, and deferred blocks created in subroutines.

Suspected ownership

This is a PerlOnJava compiler/runtime control-flow and call-frame compatibility defect. The exact ownership should be reduced before implementation:

1. Trace how defer blocks are represented and scheduled at scope exit.
2. Compare scheduling relative to loop continue, next, last, redo, return, die, and normal block completion.
3. Inspect call-frame construction and caller filtering for deferred execution.
4. Verify whether the ordering and caller-frame failures share an implementation cause.
5. Run focused reproductions on both JVM and interpreter backends; the archived regression confirms the default JVM backend only.

No missing service, native dependency, timeout, or upstream test defect is involved.

Regression coverage and acceptance criteria

• Add system-Perl-validated project regressions for defer ordering around continue and for caller visibility.
• Verify normal scope exit, loop control flow, exceptions, nested defers, and deferred blocks created in subroutines.
• Match standard Perl caller results without exposing implementation-only anonymous frames.
• Pass the focused regressions on both JVM and interpreter backends.
• Re-run the unchanged Feature::Compat::Defer 0.02 suite and require all 30 tests to pass.

No exact existing PerlOnJava issue covers these feature 'defer' failures.