fix: render the view "Back" lands on after the popup is reopened (closes #268)

goBack() only unhid its target. A reopened popup renders the wallet list
and the one view restoreView() lands on, so every other view is still the
blank static template from index.html: pressing Back from Settings onto an
address showed an empty address line and no balances, and the same held for
address-token, receive, confirm-tx and transaction.

The per-view dispatch and its data guards move out of restoreView() into
src/popup/viewRouter.js, and goBack() now routes a popped view through the
same code by way of a renderer index.js registers with setBackRenderer().
A view whose backing state is gone falls back to Home the way the restore
does, rather than showing an empty template.

The Back path renders only a view this page load has not rendered yet.
viewRouter.js keeps a page-load-scoped set of rendered views, written by
showView() — the last thing every render path runs, forward navigation and
the restore alike, so a view added later registers itself rather than
needing to be remembered. Back onto a view already in that set unhides it
and nothing more, exactly as it does for a view outside RESTORABLE_VIEWS:
rendering a second time would re-fetch and overwrite what the view holds,
such as an edit typed into Settings and not yet saved. Home stays the
exception and is re-rendered on every Back, as it was when goBack() called
the renderWalletList() registered through setRenderMain(), so the wallet
list reflects what changed while the user was away from it.

tests/backNavigation.test.js drives the real goBack() over the reproduction
and over each of address-token, receive, confirm-tx, transaction, success-tx
and error-tx, with and without their backing state, and pins that a view
this page load already rendered — a live-session view, or Settings revisited
— is only unhidden, while Home still re-renders. tests/e2e/run.js adds three
cases against the real popup in a real browser, because make check cannot
see a blank view: a real close and reopen then Back onto the address screen
and onto Receive, and an in-session Back onto Settings that must keep
unsaved input. All three were demonstrated failing first.

README.md

@@ -638,6 +638,21 @@ ExportPrivKey and ShowRecoveryPhrase — are deliberately absent from that list,
 so the popup can never reopen onto one of them with no password prompt in front
 of it.
 
+A reopened popup renders the wallet list and the one screen it restores onto,
+and nothing else, so every screen on the stack behind that one is still the
+blank template from `index.html`. "Back" therefore renders its target rather
+than only unhiding it, through the same dispatch and data guards as the restore
+(`src/popup/viewRouter.js`), and falls back to Home when the state the target
+would render is gone.
+
+It renders only a screen this page load has not rendered yet. Forward navigation
+renders as it goes, and `viewRouter.js` records every screen that reaches
+`showView()`, so "Back" onto a screen already on the page unhides it and nothing
+more — rendering it a second time would re-fetch and overwrite what it holds,
+such as an edit typed into Settings and not yet saved. Home is the one screen
+"Back" always re-renders, so the wallet list reflects anything that changed
+while the user was away from it.
+
 Every screen that holds secret material in the page registers a cleanup with
 `onViewLeave()` (`src/popup/views/helpers.js`), which `showView()` runs on every
 exit from that screen rather than only on its "Back" button, so nothing secret