PrereqScanner TestNeeds loses quoted module names and version literals

从 t/test.t 中 upstream 失败的用例开始，先使用 system Perl 复现它们，然后在 JVM 和解释器后端上复现。跟踪带引号的字面量和数值字面量经过 parser/compiler 值路径以及 PPI/PPIx::Literal 兼容层的过程。完成的标准是，项目自身的回归覆盖能够在两个后端上一致地保留多个模块名和 5.020 版本。

Summary

Perl::PrereqScanner::Scanner::TestNeeds v0.001 regressed on PerlOnJava.
The scanner no longer preserves quoted module names or Perl version literals
when processing use Test::Needs statements.

The regression reproduces identically on both the JVM backend and the
interpreter backend.

CPAN evidence

• Distribution: Perl-PrereqScanner-Scanner-TestNeeds v0.001
• Module: Perl::PrereqScanner::Scanner::TestNeeds
• CPAN run: 20260915-125610-17469
• Result: 2/3 assertions failed; 1/2 test programs failed
• Previous passing result: 2026-08-27, commit 4ebea751e
• Standard Perl: complete upstream suite passes, 9 tests
• PerlOnJava: 2 assertions fail, followed by an invalid-version exception
• Native code: none in the target distribution or its relevant dependencies

The failing upstream tests are t/test.t assertions for one and multiple
module prerequisites. The failure occurs after the module's load test passes.

Reproduction

use Perl::PrereqScanner;

my $scanner = Perl::PrereqScanner->new({ scanners => ['TestNeeds'] });

my $prereqs = $scanner->scan_string(
    q{use Test::Needs 'Local::Module1'}
);

use Data::Dumper;
print Dumper($prereqs->as_string_hash);

Expected under standard Perl:

{ 'Local::Module1' => 0 }

Observed on both PerlOnJava backends:

{ '' => 0 }

The version-literal case also differs:

$scanner->scan_string(q{use Test::Needs { perl => 5.020 }});

Expected:

{ perl => '5.020' }

Observed:

{ perl => '5.000' }

The upstream test then aborts with:

Can't convert '': Invalid version format (version required)

Backend scope

The exact upstream test command fails on both execution backends with the
same results:

• JVM backend: Local::Module1 and Local::Module2 are missing from the
  prerequisite map; the test ends with invalid-version parsing.
• Interpreter backend: the same missing module names and invalid-version
  failure occur.

Likely ownership

The target module's implementation delegates source literal handling to
PPIx::Literal and prerequisite accumulation to Perl::PrereqScanner. The
failure is not in the upstream distribution: its complete suite passes under
standard Perl.

The PerlOnJava result suggests a shared literal/value representation defect:

• quoted string literals are converted to an empty string;
• version-like numeric literals lose their significant digits and become
  5.000 instead of 5.020;
• the resulting values are then passed into the scanner and version parser.

The regression should be investigated in the parser/compiler value path and
the PPI/PPIx::Literal compatibility layer, rather than by changing the CPAN
module or its tests.

Impact

This breaks static prerequisite scanning for Test::Needs, causing module
requirements to be silently recorded under the wrong name or omitted. It can
also misrepresent Perl version requirements, potentially allowing an
incorrect prerequisite set to pass validation or causing downstream tools to
abort with invalid-version errors.

Because Perl::PrereqScanner is used by CPAN tooling and distribution build
systems, the defect may affect more scanners and prerequisite declarations
than this small test distribution exposes.

Expected fix

Preserve the exact value and type of PPI/PPIx::Literal results when scanning
quoted strings and numeric/version literals. In particular:

1. use Test::Needs 'Local::Module1' must produce
   Local::Module1 => 0.
2. Multiple quoted module names must all be retained.
3. perl => 5.020 must retain the Perl version value 5.020.
4. JVM and interpreter backends must agree.

Add permanent project-owned regression coverage, validated first with system
Perl, for quoted module names, multiple module names, and Perl version
literals.

Deduplication

GitHub searches were performed for PPIx::Literal, Perl::PrereqScanner,
Test::Needs, the empty-string prerequisite symptom, and the 5.020 version
conversion.

No existing issue directly covers this regression. Existing parser/runtime
issues found by the search concern unrelated behaviors, including DBI trace,
Unicode regex handling, typeglob localization, and hash-reference aliasing.

This report is therefore not a duplicate.