Found during live verification of the escrow: I had added the fallback only to
decryptPartnerAnswer, the DAILY path. Daily answers are schemaVersion 2 —
couple-key encrypted, gated by rules, not ECIES-sealed. The sealed system's live
surface is question THREADS. So the escrow healed the path that doesn't need it
and left the one that does still failing on a second device: exactly the bug,
untouched, behind a fix that looked complete.
Worth naming the pattern: the exploration notes said this plainly ("the live
blast radius today is question threads"), and I still wired the fix to the
first call site I read. Reading the map is not the same as following it.
decryptPartnerThreadAnswer now takes the same escrow fallback. Mutation-checked:
reverting it to a bare loadPrivateKey() fails exactly the new test.
Diagnostics from the live run removed. The escrow write itself is confirmed
accepted by the DEPLOYED rules — an instrumented run showed "existing=true" on
a device that had published one on an earlier Home load, which also proves the
idempotence guard skips correctly.
2f16d1e09c