chore(ext/node): strengthen scrypt regression test for 128-byte keylen (#34601)

## Summary

The existing `log_n > 64 doesn't panic` test, added with the AWS-LC
scrypt
migration, was misnamed (it actually tests `keylen=128` with default
options,
not `log_n > 64`) and resolved its promise unconditionally — so a silent
failure inside the callback would not surface.

Replace it with two assertive tests against the original reproduction
from
denoland/deno#27716:

- `scrypt with 128-byte keylen matches Node` runs both the async and
sync APIs
with `keylen=128` and asserts the output matches Node.js's hash
byte-for-byte.
- `scrypt handles concurrent 128-byte keylen calls` issues two scrypt
calls in
parallel (mirroring the original report's double panic) and verifies
both
  callbacks fire cleanly with identical output.

The Node-compatible behavior itself was already implemented when scrypt
switched to AWS-LC's `EVP_PBE_scrypt` in #33773; this just hardens the
regression coverage so a future regression would be caught.

Closes denoland/orchid#353

## Test plan

- [x] `dprint fmt` clean
- [x] `deno lint --config tests/config/deno.json` clean
- [x] Expected hash verified to match Node.js's output and the stable
Deno
      2.8.1 release
- [ ] CI: `cargo test unit_node::crypto::crypto_scrypt_test`

Co-authored-by: divybot <divybot@users.noreply.github.com>
Co-authored-by: Divy Srivastava <me@littledivy.com>