test(amplify-category-auth): generate ephemeral EC key at runtime instead of committed key literal

[Simone319]

Problem

Secret scanning (acat-bosco/rsa-private-key, HARD_CODED_RSA_PRIVATE_KEY_DETECTED) flags
packages/amplify-category-auth/src/__tests__/provider-utils/awscloudformation/utils/extract-apple-private-key.test.ts
for a committed private-key literal.

The committed value is a real, cryptographically valid P-256 (prime256v1) private key —
not a malformed placeholder. Verified: openssl pkey -inform DER parses it as a 256-bit
NIST P-256 key, and a sign→verify round trip succeeds. It is genuine, signature-capable key
material.

Per the in-repo comments accompanying the sibling copies (sample.env: "the following keys
are invalidated but they pass Cognito validation"; envVars.ts: "this is an invalidated
key"), the key was deliberately revoked/invalidated on the Apple side — it is retained
only because it is structurally valid enough to pass Cognito's config-time validation. So
this is not believed to be a live credential, but it is real key material and should not
be committed to source.

Correction note: an earlier revision of this description claimed the value was
unparseable/inert. That was wrong — it came from testing with openssl ec (which expects
SEC1) against a PKCS#8 key. The value parses fine with openssl pkey. Correcting the
record here to avoid anyone dismissing this as a non-issue.

Fix

extractApplePrivateKey only needs a key-shaped string — it strips whitespace and pulls
the base64 body out from between the PEM markers. It performs no cryptographic validation, no
algorithm check, and no Apple-side lookup. The test therefore does not need a real or
registered key at all.

Generate an ephemeral P-256 key at runtime (crypto.generateKeyPairSync, curve
prime256v1 — the ES256 curve Sign in with Apple uses) once at describe scope, and derive
the expected value from it via
createPrivateKey(pem).export({ type: 'pkcs8', format: 'der' }).toString('base64').

Result: zero static key material in source, nothing for the scanner to match, and no
hardcoded literal or length to drift.

Scope / risk

• Test-only. No production or customer code path is touched;
  extract-apple-private-key.ts is unchanged.
• Both existing assertions are preserved in meaning: wrapped PEM → bare one-line base64
  body, and idempotence for an already-extracted key.
• The generated PEM is passed verbatim — the function strips all whitespace and its -+
  marker pattern is dash-count agnostic, so no massaging is required.

Bonus: better coverage

The old fixture was retained purely as a static string, so the test only ever exercised
string munging against one frozen value. It now runs against a freshly generated, valid
P-256 PKCS#8 key on every run.

Not covered by this PR

The same key is committed in 8 other files (9 further occurrences) — amplify-e2e-core
(envVars.ts, auth-utils.ts), amplify-e2e-tests/sample.env, and 5 codebuild_specs/*.yml.
Those are addressed separately, since they feed real E2E runs and need a CI-secret
mechanism rather than a generated key.

Verification

jest on this file: 2 passed, 2 total (exit 0). Additionally confirmed the test is not
vacuous — against a mutant extractor that skips marker extraction, assertion 1 fails as
expected.

[sarayev]

Do we need to clean up other occurrences of hardcoded key literals from the repo?