fix(client): recover identity keys from what the browser already has

Registering in Firefox and coming back to it said "This browser does not hold
your keys" — while both halves of those keys were on disk a few bytes apart.

_sessionKeys lives in sessionStorage, which dies with the tab. The encrypted
keypair bundle is in localStorage from registration, and the key that opens it is
in IndexedDB from login, but nothing ever put the two together again: only the
login path did, and a returning user is restored from stored auth without logging
in. So closing a tab looked identical to never having registered there.

Recovery now happens before connecting: bundle from localStorage, key from
IndexedDB, public half derived from our own secret rather than read back from the
hub. The bundle is also queued for backup to the node, which is what lets a
second browser recover the same keys with the password.

Not hardening, and not from the invite redesign — an oversight in session
restore that the redesign made visible, because joining is now the first thing
that needs those keys.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions