fix: filter the restored view stack against RESTORABLE_VIEWS (closes #224)

restoreView() refuses to reopen the popup ONTO a non-restorable view, but
the stack behind it was restored verbatim, so a screen the popup will not
render -- export-privkey, show-phrase -- could sit in it. Back then landed
on a view the popup had declined to restore, and show-phrase has no Back
control to leave by. No secret is exposed: those screens are empty
precisely because nothing is restored into them. This is navigation, not
disclosure.

loadState() now truncates the stored stack at the first entry outside
RESTORABLE_VIEWS rather than splicing that entry out, so the result stays a
prefix of what was stored and every surviving entry keeps exactly the Back
target it had; splicing would silently re-point the entry above the hole at
a different screen. A stack truncated to nothing under a restorable
non-root view gets main beneath it, so Back always has somewhere to go.
Stacks with no unrenderable entry are restored unchanged. A stored stack
that is not an array runs through the same rule instead of returning early,
so a corrupt stack does not fall back on the goBack() behaviour the
explicit main exists in order not to depend on.

The filter is on load, not on save: the live in-session stack is
legitimate, since the screen really is rendered while the popup is open,
and only a load-side filter also repairs the stacks already in storage,
including ones written before a view left the set.

Out of scope, tracked separately: a restorable view sitting in the stack is
unhidden by goBack() without being re-rendered, so it can still come up
blank on a freshly reopened popup. That is a general navigation defect,
independent of this filter, and is
#268.

TODO.md

@@ -44,6 +44,14 @@ undefined identifiers, which is how
 
 # Completed Steps
 
+- 2026-08-12: The restored navigation stack is filtered against
+  `RESTORABLE_VIEWS` on load, truncated at the first entry the popup would not
+  render so that every surviving entry keeps the Back target it had. Back after
+  reopening can no longer land on a view the popup declined to restore, such as
+  `export-privkey` or `show-phrase`
+  ([#224](https://git.eeqj.de/sneak/AutistMask/issues/224)). Restorable views in
+  the stack are still unhidden without being re-rendered; that is tracked
+  separately in ([#268](https://git.eeqj.de/sneak/AutistMask/issues/268)).
 - 2026-08-12: One wording for a rejected password on every screen that asks for
   one — the send confirmation and the delete-wallet confirmation no longer say
   "Wrong password." (a fragment, which `RULES.md` Language & Labeling forbids)