fix(storage): preferences and automation rules are lost across an identity change

[kNoAPP]

Part of #353, but a live bug today — worth fixing regardless of whether the rest of that epic ships.

Problem or Motivation

Restoring a backup with the identity onto a radio whose current public key differs silently discards the restored preferences and automation rules. That is precisely the flagship recovery scenario from #299: the radio died, and the backup is being restored onto a replacement.

The cause is ordering. session.ts:127 awaits flushSessionAsync before importPrivateKey at session.ts:134:

const persisted = await flushSessionAsync(client);   // writes under the OLD pubkey
...
await client.importPrivateKey(key);                  // identity changes here

flushSessionAsync reads client.selfInfo.pubkey and the module-level storageKey (persistence.ts:117-129), both bound at connect from the pre-import identity. So all four blobs are written into the old identity's namespace, encrypted under the old radio-derived key.

The identity then swaps and the radio reboots. The dropped link routes to beginReconnect, not teardownSession (useMeshCore.ts:460), so store.reset() never runs and the in-memory data survives. On reconnect the app derives a fresh key and namespace from the new public key and hydrates an empty record. From there the four blobs diverge:

• msgHistory survives, by accident. restoreHistory merges rather than replaces (meshStore.ts:1468) and always returns a fresh object, which trips the save subscription's state.msgHistory !== prev.msgHistory check and rewrites it under the new key.
• advertCache survives — merged, then written explicitly by flushAdvertCache(c).
• preferences are lost. A null blob coerces to {} and every field normalizes to its default (meshStore.ts:1338).
• automationRules are lost. restoreAutomationRules(rules ?? []) is a plain set({ automationRules }) (meshStore.ts:1718); the ?? [] wipes them.

Two further consequences:

• The write leaves an orphaned encrypted record under the old public key that nothing ever collects.
• applyBackup returns persisted: true, and the UI reports success, for a write that landed in a namespace the user will never read again.

Proposed Solution

Make a deliberate public-key change carry the browser data with it, rather than flushing into the outgoing namespace.

• Do not flush before the identity write when opts.restoreIdentity is set and the backup's identity differs from the live one. The in-memory store already survives the reconnect; the flush is what misfires.
• After the reconnect binds the new key, write all four blobs under the new namespace — not only the two that currently survive by side effect. The hydrate must not normalize preferences and automation rules to defaults when the store already holds restored values for them; the existing explicit flag on restorePreferences is the precedent for distinguishing the two cases.
• Delete the old namespace's records once the new ones are written, so a deliberate identity change does not leave a readable orphan behind.
• ApplyResult.persisted must describe the namespace the user will actually read from.

This is a prerequisite for the seed-identity wizard, which performs the same import-then-reboot sequence on every run.

Verification

Restore a backup containing an identity, preferences and automation rules onto a radio with a different current identity. After the reboot and reconnect, all four blobs must be present, and the old record must be gone.

[kNoAPP]

The bug is real — one correction to the mechanism, which changes the fix

Fix is up in #369. The diagnosis of where the data goes is exactly right:
flushSessionAsync namespaces by client.selfInfo.pubkey and encrypts under
the session key, both bound at connect from the pre-import identity, so the four
blobs land in the outgoing identity's namespace.

One premise does not hold, and it matters.

The radio does not reboot on import

This ticket says "The identity then swaps and the radio reboots. The dropped
link routes to beginReconnect, not teardownSession, so store.reset() never
runs and the in-memory data survives." The firmware handler is:

} else if (cmd_frame[0] == CMD_IMPORT_PRIVATE_KEY && len >= 65) {
    ...
    if (_store->saveMainIdentity(identity)) {
      self_id = identity;
      writeOKFrame();
      resetContacts();
      _store->loadContacts(this);
    }

No reboot(), no restart. Nothing in this app reboots it either —
MeshCoreClient.importPrivateKey's TSDoc says so explicitly ("it needs a reboot
before the new identity is fully in effect, which this method does not
perform"), and the UI tells the user "Backup restored — reboot the radio to
finish switching identity."

So there is no drop, no beginReconnect, and no reconnect in that window. The
session continues on the outgoing identity and keeps persisting to its
namespace.

What that changes

The loss happens later, whenever the user reboots — and how they reboot
decides the damage:

• Settings → Reboot. The tab survives, so the in-memory store survives, and
  this ticket's "msgHistory and advertCache survive by accident" holds.
  Preferences and automation rules are lost, as described.
• Power-cycle, or a reload first. The store goes too. All four blobs are
  lost, not two.

The second path is the one that message invites, and it is why the proposed
remedy — "after the reconnect binds the new key, write all four blobs under the
new namespace" — is not sufficient on its own. For a power-cycle there is no
reconnect in that page session and nothing left in memory to write from.

What #369 does instead

Writes the incoming identity's namespace at restore time, once the radio has
accepted the key, deriving that identity's key from the radio's current channel
secrets salted with the backup's public key — the same inputs the next connect
uses, since a key import leaves channels untouched. That makes the data durable
immediately and covers every reboot path, including a power-cycle and a reload.

Bullets 1, 2 and 4 are satisfied. Bullet 2's "the hydrate must not normalize to
defaults" is met by construction rather than by a guard: the records are already
there when the hydrate reads them.

Left open

Bullet 3, deleting the outgoing namespace's records. With no reboot, the
session legitimately continues on the outgoing identity and keeps writing to it,
so deleting those records while they are still live would be wrong and the save
subscriptions would recreate them anyway. Correct cleanup has to happen on the
next connect, once the new public key is confirmed, and needs state that
survives a power-cycle and a page reload. Worth its own ticket — say the word
and I will file it.