Found by live-verifying the rotation on a throwaway couple: after the partner
rotated, the other device cold-started into its last screen — a conversation —
and every message written under the new key rendered "🔒 Couldn't unlock on this
device". It stayed that way until the user happened to tap Home, because that's
the only place adoption ran. A chat notification opens a conversation directly,
so this is the normal path, not a corner case: the partner's phone would look
broken for as long as they avoided Home.
The couple key is an app-level fact, so adopting it is app-level work. New
CoupleKeyRotationAdopter runs on the startup path beside FCM registration (same
authState collect + best-effort runCatching shape as registerFcmToken), and Home
now calls the same use case instead of its own inline copy — one home for the
logic, with an entry point for callers that already hold the couple (no
redundant read) and one that resolves it. Failures go to CrashReporter per the
house pattern; never throws, because a device that can't adopt right now is not
broken — all pre-rotation content still decrypts and every later launch retries.
Verified live on the throwaway couple, two rotations deep (generations 0→1→2):
the partner cold-starts and reads all four messages across all three key eras,
zero locked placeholders. The proof the startup path is what's doing it: Home
logs only when IT adopts, that log never fired, and the content still decrypted
— Home found the key already current because MainActivity had adopted first.
Android suite green, assembleDebug clean.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
8b0bc58231