Chunk-2 finding 2 from the second-opinion re-review (silent-failure CRITICAL). Every SignerFor failure — wrong KEK, corrupt ciphertext, missing actor — was one opaque error chain the worker classified "transient, retry": a permanently wrong or half-rotated BRIDGE_KEK retried until the budget poisoned, hours later, under text reading "message authentication failed" — corruption-flavored, while new actors (sealed under the wrong key consistently) kept working: the most confusing possible split. - New typed KeyUnsealableError/ErrKeyUnsealable: Custodian.open returns it only after every configured KEK refused well-formed bytes; format/version errors keep their validation classification, so the reseal walk's malformed-vs-wrong-key split is unchanged. The message names BRIDGE_KEK (and BRIDGE_KEK_PREVIOUS mid-rotation) and says configuration, not corruption. - The worker poisons IsKeyUnsealable immediately under new class kek_misconfigured (added to neverReachedTheWireClasses per that file's contract) — retrying cannot change the answer, and the fast poison surfaces the cause in minutes. A sanctioned rotation cannot hit it: the runbook's own ordering (previous-KEK window, actor tables resealed before the rotation row, retire only on a clean zero-run) is spelled out at the branch. Signer NotFound still retries. - The boot canary no longer self-satisfies: with no rotation-key row, LoadOrCreateRotationKey now proves the KEK against sampled sealed actor material (ap_actors + bridged_actors) before minting, and only a database with no sealed material anywhere — a genuinely fresh install — may mint on an unproven key. Previously a wrong KEK plus an absent row sealed a fresh key under the wrong KEK and reported success. DEPLOY.md: the kek_misconfigured triage entry and the restore-drill canary claim (now true even when the restore lost the rotation row). Repro tests red-first across all three parts, including the self-satisfy canary red and the worker classification revert-check. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>