Fix @INC hook generator state handling for filtered v0.0.7

[fglock]

Summary

filtered v0.0.7 fails under PerlOnJava because the state returned by a Perl @INC hook generator is read from the wrong list position.

This was observed in CPAN random tester run 20260908-125510-82561, recorded as filtered::v0.0.7 nested under PPI::Transform::PackageName.

Reproduction

The upstream filtered test suite passes under system Perl:

• 19 test programs discovered
• 156 runnable tests passed; PPI-dependent tests were skipped because PPI was unavailable

Under PerlOnJava, the focused upstream test t/simple.t fails on both backends:

• JVM backend: 8/16 failures
• Interpreter backend: 8/16 failures

Representative failures are:

• Can't load FilterTest by FilterTest.pm did not return a true value
• expected BARBARBAR, got FOOFOOFOO
• expected BARFOO, got FOOFOOFOO

The full CPAN run failed 81/222 subtests across 12/19 test programs. The failure is reproducible without XS, network services, or other platform prerequisites.

Root cause

filtered::hook::INC returns a generator and its initial state as:

return (sub { ... }, 1);

The generator expects the second argument ($_[1]) to be the state. On its first call, state 1 causes it to inject use MyFilter;; on the next call, state 0 ends the generated source.

PerlOnJava's ModuleOperators.readIncHookSource() currently parses the returned values as though the state were the fourth item:

RuntimeScalar third = values.get(2);
if (third != null && third.type == RuntimeScalarType.CODE) {
    sourceSub = (RuntimeCode) third.value;
}

state = values.get(3);

For the valid two-item return (CODE, 1), state therefore becomes null. readIncHookGenerator() calls the generator without $_[1], so the generator takes the EOF path immediately and returns an empty source string. This produces the did not return a true value error on repeated loads; the first load can proceed without the intended source filter, which explains the unchanged FOO... results.

The relevant implementation is the @INC hook source decoding in ModuleOperators, specifically readIncHookSource() and readIncHookGenerator(). The fix should preserve the documented return forms while passing the second list element as generator state when the first element is a generator coderef, without confusing it with the filehandle/filter form.

Expected behavior

The two-item return (CODE, state) should invoke the generator with that state as $_[1], produce the requested module source, and allow filtered to apply its Filter::Simple closure filter. The upstream t/simple.t should pass 16/16 in both PerlOnJava backends.

Additional regression coverage

Add a project-owned focused regression test for a two-item @INC hook return (CODE, state), including state transition from 1 to 0. Retain filtered's t/simple.t as integration evidence.

Environment

• PerlOnJava run ID: 20260908-125510-82561
• Distribution: filtered v0.0.7
• System Perl: 5.42.2
• PerlOnJava: current master at the time of the run
• Affected backends: JVM and interpreter