crypto: use of more primordials broke webcrypto's aes decrypt

[panva]

#36012 broke webcrypto's use of ArrayBufferView (and the like) in at least AES decrypt operations.

• Version: v15.2.0
• Subsystem: crypto.webcrypto

What steps will reproduce the bug?

This snippet works in v15.1.0, but fails in v15.2.0

// some.mjs

import { webcrypto as crypto } from 'crypto'

const secretKey = await crypto.subtle.generateKey(
    {
        name: "AES-GCM",
        length: 256,
    },
    false,
    ["encrypt", "decrypt"],
)

const iv = crypto.getRandomValues(new Uint8Array(12))
const aad = crypto.getRandomValues(new Uint8Array(32))

const encrypted = await crypto.subtle.encrypt(
  {
      name: "AES-GCM",
      iv,
      additionalData: aad,
      tagLength: 128
  },
  secretKey,
  crypto.getRandomValues(new Uint8Array(32))
)

await crypto.subtle.decrypt(
  {
      name: "AES-GCM",
      iv,
      additionalData: aad,
      tagLength: 128,
  },
  secretKey,
  new Uint8Array(encrypted),
)

How often does it reproduce? Is there a required condition?

What is the expected behavior?

All webcrypto arguments that are ArrayBuffer can also be Int8Array | Int16Array | Int32Array | Uint8Array | Uint16Array | Uint32Array | Uint8ClampedArray | Float32Array | Float64Array | DataView.

What do you see instead?

#36012 use of ArrayBufferPrototypeSlice in lib/internal/crypto/aes.js broke this particular snippet, possibly other too.

TypeError: Method ArrayBuffer.prototype.slice called on incompatible receiver [object Uint8Array]
    at Uint8Array.slice (<anonymous>)
    at node:internal/per_context/primordials:23:32
    at asyncAesGcmCipher (node:internal/crypto/aes:186:13)
    at Object.aesCipher (node:internal/crypto/aes:209:28)
    at cipherOrWrap (node:internal/crypto/webcrypto:625:10)
    at SubtleCrypto.decrypt (node:internal/crypto/webcrypto:640:10)
    at file:///Users/panva/repo/node/some.mjs:26:21

[panva]

cc @jasnell @Trott @aduh95 (for #36012)

[aduh95]

Thanks a lot for the report and the repro snippet. I have added a fix and a test case in #36087.