fix(state): share storage key between state init and named-sub capture

[fglock]

Summary

Fix a bug where a state variable declared in a block at top level (no enclosing sub) and referenced by a named sub defined in the same block was read as undef inside the sub, even after the outer block had initialized it.

Found while investigating jcpan -t QRCode::Encoder, which failed across 3 test files because QRCode::Encoder::QRSpec uses this pattern heavily:

{
    state $table = [ ...big data... ];
    sub qrspec_data_size ($version, $level) {
        my $item = $table->[$version - 1];   # $table was undef!
        return $item->{words} - $item->{ec}{$level};
    }
}

Root cause

The persistent-variable key differed between the two sides:

• state $x = ... stores the value in global storage under PersistentVariable.beginVariable(sigilNode.id, name), where sigilNode.id is assigned by OperatorParser for state declarations.
• When a named sub captures the same lexical, SubroutineParser allocated a separate begin id via RuntimeCode.evalBeginIds.computeIfAbsent(ast, k -> classCounter++), producing a different global key. The sub's captured field was thus a fresh empty scalar.

Fix

1. In the named-sub capture path (SubroutineParser), for state declarations reuse the existing ast.id as the begin id instead of allocating a new one, and register it in evalBeginIds.
2. As a safety net, StateVariable.retrieveStateScalar/Array/Hash now fall back to global storage when the per-sub map has no entry, so a sub accessing a state var declared in an outer (non-sub) scope still sees the shared storage.

Test plan

• Minimal repro: { state $t = [10]; sub f { $t->[0] } }; print f() now prints 10.
• State-per-closure-instance semantics still correct (verified with make make() + state $c = 0; ++$c — instances still have independent counters).
• jcpan -t QRCode::Encoder — all tests pass (t/00-load, t/01-hello, t/02-best, t/03-version-7; also Math::ReedSolomon::Encoder dependency).
• make (unit tests) passes.

Generated with Devin