decimalizePvv() was using a single-pass that immediately mapped A-F to
0-5. The Visa PVV spec (matching ANSI X9.8 and jPOS behavior) requires
two-pass: collect all decimal digits (0-9) first; only then re-scan
mapping A=0 B=1 C=2 D=3 E=4 F=5. This matches decimalizeCvvHex() which
was already correct. Bug produced wrong PVV whenever a hex letter appeared
before the first decimal digit in the encrypted output.
Test vectors updated from "6077" (single-pass result) to "6776" (correct
two-pass result) for the encrypted PVV hex 6A77E65CFE349D60.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
e864259c1e