Parser executes trailing comment text on shebang lines

[fglock]

Summary

PerlOnJava does not fully discard a shebang/comment line when it contains a second # comment marker. Both backends execute text from the trailing Perl::Critic annotation as Perl code/output and consequently mishandle the script arguments that follow.

Reproduction

CGI-Compress-Gzip 1.03 contains t/testhelp, whose first line is:

#!perl -w ## no critic (RequireVersionVar)

Run the helper with its normal test arguments:

jperl -Iblib/arch -Iblib/lib t/testhelp -DHTTP_ACCEPT_ENCODING=gzip simple 'Hello World!'

Expected, as on standard Perl: a gzip response for Hello World!.

Actual on both the JVM and interpreter backends: the response is uncompressed, reports that the user agent does not accept gzip, and its body begins with:

nocritic(RequireVersionVar)-DHTTP_ACCEPT_ENCODING=gzipsimpleHello World!

The trailing comment contents and command-line arguments must not become program output. Perl should discard the complete shebang/comment line before compiling the script.

CPAN evidence

In CPAN random run 20260925-103132-20451, CGI-Compress-Gzip 1.03 failed 21 of 44 subtests in t/gzip.t on the JVM backend. The subprocess-response cases are directly caused by this parser defect. The same source passes all 44 tests under the standard-Perl oracle.

The focused helper reproduction also fails on the interpreter backend, so this is shared parser behavior rather than a JVM-only emission issue.

Acceptance criteria

1. A script beginning with #!perl -w ## no critic (RequireVersionVar) does not emit any part of that line.
2. Its @ARGV remains -DHTTP_ACCEPT_ENCODING=gzip, simple, and Hello World! when launched with those arguments.
3. The focused reproducer passes on standard Perl, PerlOnJava JVM, and PerlOnJava interpreter backends.
4. CGI-Compress-Gzip's subprocess-response tests no longer contain the annotation or argument text in their bodies.