fix: an open popup moves to the recovery screen when its profile becomes unreadable (closes #373)

A popup already open when the stored profile became unreadable stayed on the
last good profile until reopened. Every save already runs the check loadState()
runs at open; a save refused by it now raises the recovery screen, stops the
ten-second refresh, and passes the screen to showView(), which runs the leave
cleanup of the screen it replaces and records it as the current view. From
then on showView() shows nothing else, so a transaction wait or a later save
cannot take the user off it or clear an export or a typed confirmation. Any
other failed save keeps the "NOT SAVED" banner. The popup test harness now
honours clearInterval().

Model: opus-5-5

README.md

@@ -1114,16 +1114,18 @@ because bumping for one would send every older install to StateRecovery for
 nothing.
 
 Every read of the record goes through `assertStateUsable()` first, on the raw
-bytes, before normalization: `loadState()` for the popup and `getState()` for
-the background. It refuses a record that is not an object, a `schemaVersion`
-this build does not understand (a newer one included), a `wallets` that is not a
-list of wallet records with address records in them, and a `networkId` that is
-not a network in `src/shared/networks.js`. Refusing is the whole point — a
-record the wallet cannot vouch for is never normalized, never written back, and
-never half-loaded. The popup shows StateRecovery; a dApp gets a specific error
-(`-32007`, an EIP-1474 server-error code the spec leaves unassigned) saying the
-saved data cannot be read and that nothing was signed or sent, rather than the
-generic `-32603` every request used to answer.
+bytes, before normalization: `loadState()` and every `saveState()` for the
+popup, and `getState()` for the background. It refuses a record that is not an
+object, a `schemaVersion` this build does not understand (a newer one included),
+a `wallets` that is not a list of wallet records with address records in them,
+and a `networkId` that is not a network in `src/shared/networks.js`. Refusing is
+the whole point — a record the wallet cannot vouch for is never normalized,
+never written back, and never half-loaded. The popup shows StateRecovery,
+whether it finds the record unreadable when it opens or at a save while it is
+open; a dApp gets a specific error (`-32007`, an EIP-1474 server-error code the
+spec leaves unassigned) saying the saved data cannot be read and that nothing
+was signed or sent, rather than the generic `-32603` every request used to
+answer.
 
 Every other field of the record is floored in `normalizePersisted()` rather than
 gated, and the floor is not the same for every field. Some are type-checked as a
@@ -1167,8 +1169,9 @@ now also reported rather than swallowed: `onSaveFailure()` in
 `src/shared/state.js` is called for every failed save, awaited or not, and the
 popup puts up a persistent "NOT SAVED" banner (`showSaveFailureBanner()` in
 `src/popup/views/helpers.js`). Storage can still fail for reasons no floor
-covers — a quota, a revoked permission, a record a newer build wrote — and the
-wallet must never look healthy while that is true.
+covers — a quota, a revoked permission — and the wallet must never look healthy
+while that is true. A save that fails because the stored record fails the gate,
+such as one a newer build wrote, gets StateRecovery instead of the banner.
 
 The `networkId` check is not cosmetic: that value is an object KEY into
 `state.networkEndpoints`, so an unvalidated `"__proto__"` would set the map's
@@ -1978,9 +1981,20 @@ view would leave a wallet one click from deletion.
 
 #### StateRecovery (`state-recovery`)
 
-- **When**: `loadState()` refused the stored profile, so the popup has no
-  profile at all. It is the only screen reached without one, and the only one
-  that never appears during ordinary use.
+- **When**: the stored profile fails `assertStateUsable()`. At open, that is
+  `loadState()` refusing it, so the popup has no profile at all. While the popup
+  is open, on any screen, it is a save refusing it: every `saveState()` reads
+  the stored record and runs the same check before writing, so the popup finds
+  it at the next navigation, or at the next ten-second balance refresh that
+  reaches the network ([#373](https://git.eeqj.de/sneak/AutistMask/issues/373)).
+  A save that fails for any other reason, such as a storage read or write that
+  errors, gets the "NOT SAVED" banner instead and leaves the screen as it is.
+  The screen it replaces is left as any navigation leaves it, so a revealed
+  phrase or key, or a typed password, is wiped. Once up, the screen stays until
+  the popup closes or the record is erased: work still running in the popup,
+  such as a transaction wait, cannot replace it, and nothing in AutistMask
+  writes over a record that fails the check, so it cannot become readable again
+  underneath. It is the only screen that never appears during ordinary use.
 - **Why it exists**: a record the wallet cannot read used to render nothing — no
   view, no message, no control — while every dApp call answered a generic
   internal error, and no reset or wipe control existed anywhere in the product.
@@ -2007,16 +2021,20 @@ view would leave a wallet one click from deletion.
       Nothing was erased." on the error line
 - **No other control is reachable.** The Settings gear is hidden while this
   screen is up, because every screen behind it renders from the profile that
-  could not be read, and `showView()` is not used to raise it for the same
-  reason — it reads and writes the state singleton.
+  could not be read. At open `showView()` is not used to raise it for the same
+  reason — it reads and writes the state singleton. Under an open popup it is
+  also passed to `showView()`, which runs the replaced screen's cleanup and
+  records it as the current view, and `showView()` shows nothing else after
+  that.
 - **Both controls are required.** An export with no reset leaves the user
   looking at a broken profile with no way to use the wallet again; a reset with
   no export destroys the only copy of a record that may hold recoverable key
   material. The typed phrase is the same barrier DeleteWalletLostPassword uses,
   and for the same reason: there is no password to gate this with, since there
   is no profile to check one against.
-- Not in `RESTORABLE_VIEWS`: it is never persisted as the current view, because
-  nothing on this path writes state at all.
+- Not in `RESTORABLE_VIEWS`, and not persisted as the current view: at open
+  nothing on this path writes state at all, and under an open popup the check
+  that raised the screen refuses the save that would record it.
 
 ### External Services