test_gap_crypto_cipher_3382_3381_2954: does not reproduce under perry-dev — re-check under --release before bisecting

[proggeramlug]

What was reported

test_gap_crypto_cipher_3382_3381_2954 fails on main as a non-snapshot gap
failure (in neither test-parity/gap_snapshot.json nor
test-parity/known_failures.json). Filed originally inside #7518 as a suspected
host-local flake.

It does not reproduce under perry-dev

Same host, Node 26.5.1 oracle, own --profile perry-dev build of
-p perry -p perry-runtime -p perry-stdlib -p perry-runtime-static -p perry-stdlib-static
at every point, object cache cleared between points, PERRY_RUNTIME_DIR pinned at
the freshly built archives:

commit	date	verdict
17c0ff952	2026-07-30	PASS
c6ed8175d	2026-07-30	PASS
33acba4c1 (main)	2026-08-06	PASS — byte-identical to node, exit 0

For contrast, test_gap_diagchannel_3082_3084_3085_3086 (filed separately) does
reproduce under the same arm at main, so the arm can catch a real regression;
this one it does not see.

What that narrows it to

The failure was observed under the release-profile harness
(run_parity_tests.sh builds --release), not under perry-dev (opt-level=1,
codegen-units=16, no LTO). Candidates, in the order worth excluding:

1. Optimization-sensitive miscompile. The test drives AES-256-CBC and
   AES-256-GCM through createCipheriv/createDecipheriv with string-encoding
   update/final overloads and a non-96-bit GCM IV — byte-exact hex output, so
   any codegen difference shows immediately. --release is thin LTO at
   opt-level=3; perry-dev is neither.
2. A stale archive in the failing arm. Build outputs are invisible to
   git status, and cargo build -p perry-runtime -p perry-stdlib does not
   emit libperry_{runtime,stdlib}.a — only the -static wrapper crates do.
   Confirm the .a mtimes moved after the build before believing the arm.
3. Object-cache reuse across differently-built compilers
   (node_modules/.cache/perry/objects).
4. Genuinely environmental. The parity harness runs tests in parallel; a
   disk-full or resource-exhaustion sweep produces spurious failures across
   unrelated tests.

Reproduce it properly before bisecting

cargo build --release -p perry -p perry-runtime -p perry-stdlib \
  -p perry-runtime-static -p perry-stdlib-static
# confirm the .a mtimes moved AFTER the build, then:
./run_parity_tests.sh --filter test_gap_crypto_cipher_3382

Do not use CARGO_PROFILE_RELEASE_CODEGEN_UNITS=16 here — parity work needs
codegen-units=1 (known release-runtime miscompile at cu=16).

If it reproduces under --release but not perry-dev, that is an
optimization-sensitive bug and the bisect should be run on --release builds.
If it does not reproduce there either, the original observation was environmental
and this can be closed.

Split out of #7518, where three gap failures were initially misfiled as
host-local flakes on the mistaken reasoning that reproducing on clean main
implied a host quirk (for the EventTarget one it implied an older unnoticed
regression, bisected to c6ed8175d).

[proggeramlug]

Re-checked under --release, as this issue asks. It does not reproduce there either, so the bisect this issue was holding open is not warranted.

Method — the gap in the evidence was that every prior run was perry-dev, so this is the release profile the failure was originally reported from, at main @ 0a2bf15bd:

• own cargo build --release (thin LTO, codegen-units=1, opt-level=3) of -p perry -p perry-runtime-static -p perry-stdlib-static. Not CARGO_PROFILE_RELEASE_CODEGEN_UNITS=16, which is the usual way to make a release build tolerable — that shortcut has its own miscompile trap and would have measured a different compiler than the one that failed;
• PERRY_RUNTIME_DIR pinned at the freshly built archives, mtimes confirmed to have moved;
• Node 26.5.1 oracle.

configuration	result
--release, single test, 3 runs	PASS 3/3
--release, full 522-test parallel sweep	PASS

The full-sweep run matters more than the isolated one: this test was reported failing inside the parallel harness, and passing in isolation would not have excluded a resource-contention effect. It passed inside the sweep, and the harness exited 0 with no new untriaged failures.

That excludes the two leading candidates this issue named:

1. Optimization-sensitive miscompile — excluded. The AES-256-CBC / AES-256-GCM byte-exact hex output is identical to node under exactly the profile that would expose a codegen difference.
2. Stale archive in the failing arm — excluded here by construction (the -static wrappers were built and the .a mtimes checked), though it remains the likeliest explanation for the original observation.

What is left is candidate 4, environmental: the original #7518 sweep's failures were spurious. Closing as not reproducing. If it reappears, the useful thing to capture is the harness's own exit status and the .a mtimes at that moment, since those are what separate a real failure from a sweep artifact.