test: drive the Settings screen in a browser and guard every popup element id (closes #229)

Nothing exercised the Settings view in a browser, and jest runs in the
node environment with no DOM, so the densest run of $("...") lookups in
the codebase was unverified at runtime. A wrong id is valid JavaScript
naming a defined function: $() returns null and the next property access
throws, which inside a view's init() aborts the rest of the popup's
init() and leaves every screen blank.

Two halves, because they catch different things.

The e2e suite (tests/e2e/run.js) gains six cases between the address
removal and dust threshold sections. They assert the About well and the
wallet list were actually written — show() populates those last, so
reading them back proves the whole of show() ran rather than just enough
of it to unhide the section — that the four Token Spam Protection
controls are real input[type=checkbox] elements defaulted on, and that
the theme and network selectors offer exactly the choices
src/shared/networks.js and index.html define while carrying the
persisted value. One filter is then toggled off and back on across a
popup reopen each way, which runs the change handler, saveState(),
loadState() and the init() assignment rather than only looking at the
screen. Each group records a coverage key and a final case demands the
exact set, so a section that silently stopped running reddens the suite
instead of shrinking it.

tests/popupElementIds.test.js is the general half and needs no browser,
so jest picks it up and it runs in make check: every literal id reached
through $(), document.getElementById(), showError()/hideError() and
showView() must exist in src/popup/index.html, no id in index.html may
be defined twice, and the scan asserts it found the code and the markup
so it cannot pass by covering nothing. Only literal arguments are
resolvable statically; $(containerId) and a lookup naming the wrong
existing element are the browser suites' job, and README says so.

Demonstrated against three deliberate breaks. A typo'd id in
settings.js reddens both halves, the e2e run reporting
"pageerror: Cannot set properties of null (setting 'checked')" against
its first test. A handler bound to the wrong but existing element passes
the static guard and reddens only the new functional case. A typo in a
view no browser suite opens reddens only the static guard.

README.md

@@ -321,6 +321,24 @@ pick it up either. Neither is wired into the Gitea workflow yet —
 docker-in-docker in CI is a separate question. Run them locally before changing
 anything under `src/popup/views/`.
 
+### Element id guard (part of `make check`)
+
+`tests/popupElementIds.test.js` asserts statically that every element id the
+popup looks up — `$("...")`, `document.getElementById("...")`,
+`showError()`/`hideError()`, and the `view-<name>` a literal `showView("...")`
+resolves to — exists in `src/popup/index.html`, and that `index.html` defines no
+id twice. A wrong id is valid JavaScript naming a defined function, so neither
+jest (node environment, no DOM) nor a linter objects to it; at runtime `$()`
+returns `null` and the next property access throws, which inside a view's
+`init()` aborts the rest of `src/popup/index.js` `init()` and leaves the popup
+blank.
+
+It runs with no browser, so unlike the e2e suites it fits inside `make check`,
+and it covers every view rather than the ones some test happens to open. It only
+sees literal arguments: a call like `$(containerId)` is invisible to it, and a
+lookup naming the wrong existing element is valid by construction. Both of those
+are the browser suites' job.
+
 ## Rationale
 
 Common popular EVM wallets have become bloated with swap UIs, portfolio