Fix IO::Async thread result propagation and triage residual failures

[fglock]

Summary

IO::Async 0.805 exposes a PerlOnJava thread-result propagation bug on both
execution backends. A thread that returns scalar or list values reaches
on_joined, but the callback receives incorrect values.

The primary goal of this issue is to fix the thread path. The other failures
seen in the same CPAN run should be investigated separately and fixed where
they are genuine PerlOnJava defects, without hiding them behind the thread
work.

CPAN evidence

• Distribution: IO-Async 0.805
• CPAN compatibility run: 20260907-103952-30956
• Target selected: IO::Async::Notifier
• PerlOnJava result: 10 of 819 subtests failed in 7 of 64 test programs
• Relevant tests: t/38loop-thread.t, t/41routine.t, and t/42function.t

System Perl with the exact distribution and isolated prerequisites passes the
focused thread/routine/function tests: 127 tests successful. The full local
system-Perl suite cannot be used as the sole baseline because this sandbox
denies socketpair and connected-datagram creation, but the non-socket focused
tests pass.

Short reproducer

This is the essential scalar/list-result portion of the upstream
t/38loop-thread.t test:

use IO::Async::Test;
use Test2::V0;
use Test2::IPC;
use IO::Async::Loop;
use IO::Async::OS;

plan skip_all => 'Threads are not available'
    unless IO::Async::OS->HAVE_THREADS;

my $loop = IO::Async::Loop->new_builtin;
testing_loop($loop);

my @result;
$loop->create_thread(
    code      => sub { return 'A result' },
    on_joined => sub { @result = @_ },
);
wait_for { @result };
is \@result, [ return => 'A result' ];

@result = ();
$loop->create_thread(
    code      => sub { return 'A result', 'of many', 'values' },
    context   => 'list',
    on_joined => sub { @result = @_ },
);
wait_for { @result };
is \@result, [ return => 'A result', 'of many', 'values' ];

System Perl passes both assertions. PerlOnJava produces 1 for the scalar
result instead of A result, and produces only 3 for the list result instead
of the complete return list. The archived run and focused reproduction show
the same behavior on JVM and interpreter backends.

Related issues

• #1136 tracks the
  separate IO::Async B::SV::REFCNT regression and the stale distropref
  expectation in t/05notifier-loop.t; that test currently expects 3 while
  system Perl and current PerlOnJava report 2.
• #1144 tracks
  Perl-compatible pseudofork. IO::Async fork-model coverage must not be
  confused with the thread-result bug here.

Other failures to investigate

The same archived run also reported:

• t/50resolver.t: Storable: corrupted binary image and no final plan.
• t/52loop-listen.t: invalid sockaddr_in handling.
• t/70future-io.t: a closed-handle failure after all 55 subtests passed.

Determine for each whether it is a reproducible PerlOnJava defect, an
unsupported socket/platform prerequisite, or a consequence of the thread
worker failure. If it is fixable, retain a focused system-Perl-validated
regression rather than treating the aggregate CPAN result as one bug.

Acceptance criteria

• Add a project-owned, system-Perl-validated regression for scalar and list
  values returned through IO::Async::Loop->create_thread.
• The short reproducer passes on JVM and interpreter backends.
• t/38loop-thread.t, and the thread portions of t/41routine.t and
  t/42function.t, pass on both backends.
• Preserve exception reporting and on_joined behavior for died threads.
• Investigate t/50resolver.t, t/52loop-listen.t, and t/70future-io.t
  independently; fix them when attributable and add focused regressions, or
  document the precise unsupported/environmental cause.
• Re-run IO-Async with the maintained distropref patches, including correcting
  the stale t/05notifier-loop.t expectation tracked by Fix IO::Async B::SV refcount regression masked by suite timeout #1136.

[fglock]

Fixed by #1300.