fix(cloudflare/state-store): treat JSON decode failures as unreadable entries

[its-rosetta]

Problem

decryptEntry in the Cloudflare state store tolerates decryption failures (the 2.0.0-beta.45 key-rotation situation) by returning undefined — but only when crypto.subtle.decrypt itself throws. For AES-CTR, a wrong key typically does not throw: it yields random plaintext bytes. JSON.parse of those bytes sits outside the try, so the resulting SyntaxError escapes into Effect.orDie and kills the entire deploy with an unrecoverable defect, instead of taking the intended return-undefined reconciliation path.

We hit this in production against entries written around the beta.45 key rotation; we have been carrying this exact fix as a patchedDependencies patch since June and it has been load-bearing since.

Fix

Move the JSON.parse inside the existing try so wrong-key garbage degrades identically to a decrypt failure (logged, entry treated as unreadable, engine reconciles). Two-line move plus comment; no behavior change for healthy entries.

🤖 Generated with Claude Code

Tests (maintainer)

The AES-CTR entry codec is extracted from the Durable Object into Cloudflare/StateStore/EntryCodec.ts (plain Web Crypto, no behavior change) so it can be unit-tested in-process. test/Cloudflare/StateStore/EntryCodec.test.ts pins:

• round-trip under a random nonce, stored as the encodeState marker form
• an entry written under a different key resolves undefined (logged) instead of throwing the SyntaxError this PR fixes
• malformed / truncated entries resolve undefined, never reject

Encryption-key rotation guarantee (maintainer)

Rolling out a new worker version is only safe if the AlchemyStateStoreEncryptionKey secret cannot rotate on the way — the beta.45 incident. The rotation mechanism is generic: the Secret provider PATCHes an existing secret with whatever value the program holds, and the state-store stack is deployed with adopt(true). So any bootstrap that reaches the stack with a state that lacks (or, after this PR, cannot decrypt) the StateStoreEncryptionKeyValue row mints a fresh Random and overwrites the real key. Two independent guards now close that:

• Cloudflare.SecretsStore.Secret gains preserveExistingValue. Once a secret with that name exists, its value is never PATCHed again (scopes/comment still reconcile). The state store's encryption-key secret opts in, so a regenerated Random — stale local bootstrap state, a flaky serving probe, an unreadable state row — can no longer rotate the key. Pinned by a live test that seeds the secret out-of-band, adopts it with a different program value, and reads the stored value back through a Worker (plain secrets keep today's overwrite semantics as the control).
• The Durable Object records a SHA-256 fingerprint of its key (k:fingerprint, outside every listed key space) on first use and refuses get/set/getOutput/setOutput/getReplacedResources with an explicit EncryptionKeyChangedError if a later boot is handed a different key. Listing and deleting stay available so a deliberate wipe is still possible. The first v8 boot of an existing store records its current key, so beta.45 leftovers keep degrading to "absent" exactly as before, but any future rotation fails loudly instead of reading everything as missing and then overwriting the still-recoverable ciphertext.

STATE_STORE_VERSION is bumped 7 → 8 in its own commit: the deployed worker is only upgraded when this version changes, so without the bump the fix never reaches an existing state store (same as #251, #468, #477). Drop that commit if the rollout should be batched with another change.