UID2-7292: prevent optout crash on malformed payload

[mcollins-ttd]

Why

A malformed payload to POST / (step=optout_submit) was crashing the Node process. Two distinct paths could escape as unhandled rejections / uncaught exceptions:

1. decrypt() in src/routes/encryption.ts. crypto.scrypt's native callback contained synchronous code (createDecipheriv, decipher.write, decipher.end) sitting outside the Promise's try scope. A throw from any of those — most notably createDecipheriv rejecting an IV of the wrong length — escaped the Promise as an uncaught exception. The decipher stream's 'error' event (bad padding from a wrong key or junk ciphertext) was also unobserved.
2. handleOptoutSubmit in src/routes/index.ts. OptoutSubmitRequest.parse(req.body) threw a ZodError directly inside the async route handler. With Express 4 having no native async-error forwarding, that throw became an unhandled rejection.

What changed

src/routes/encryption.ts

• Reject a bad IV length (!== 16) synchronously before entering the new Promise(...) body, so the error surfaces as a normal Promise rejection the caller can try/catch.
• Wrap the createDecipheriv + stream setup inside the scrypt callback in try/catch, routing any throw through reject.
• Subscribe to the decipher's 'error' event so async failures (bad padding) also reject the Promise instead of going unobserved.

src/routes/index.ts

• Wrap OptoutSubmitRequest.parse(req.body) in try/catch; on failure, log via errorLogger and respond with 400 via next(createError(400)).

src/bin/www.ts

• Add a diagnostic-only unhandledRejection listener that logs via errorLogger (so any future regression at least surfaces in monitoring).
• No uncaughtException handler. Node's docs are explicit that resuming after one leaves the process in undefined state; the pod supervisor (k8s) is the right restart mechanism.

Follow-up (separate PR)

The file-level try/catch + next(createError(400)) pattern is now duplicated three times in src/routes/index.ts (email_prompt, optout_submit, defaultRouteHandler). The right idiomatic fix is a centralized Express error middleware + a small validateBody(schema) middleware (and ideally an Express 4 → 5 upgrade so async handler rejections forward natively). Out of scope for a crash-fix PR; will follow up.

Test plan

• CI build (yarn build) and lint pass
• yarn test passes locally
• Manual: POST malformed JSON to / → 400, no crash
• Manual: POST { step: 'optout_submit', encrypted: 'garbage' } (wrong format) → friendly error page, no crash
• Manual: POST with IV slot that decodes to ≠16 bytes → friendly error page, no crash
• Manual: POST with valid IV but corrupted ciphertext (bad padding) → friendly error page, no crash, decipher 'error' logged
• Manual: happy path optout still succeeds