test: tighten two checks in the persisted-field harness (closes #379)

The polarity check now counts only `hostile` and `falsy` values, not a
`hostileRestore` value, which reaches only the views its entry names.
The stale index 5 moves into `hostile` for `selectedWallet` and
`selectedAddress`, as each field's one value still truthy after the
floor.

Each `hostileRestore` entry declares whether its boot lands on its view
or falls back to Home, and the test checks the one view on screen. A
value driven onto every restorable view lists only the views it falls
back on, so a view added later is driven by default.

The header and the README restate the remaining limits as built and say
which boots are held to where the popup lands.

Model: opus-5-5

README.md

@@ -1263,14 +1263,21 @@ path rather than on the home screen. Read the claim narrowly, as that file
 states it: what those boots prove is no structural dereference on the code paths
 a WHOLLY-CORRUPTED PROFILE takes, which is not every path a stored record takes.
 Not driven: any pairing of values the four slots do not produce, a view only
-forward navigation opens, anything behind a click, and everything a healthy
-profile reaches. Within that boundary the verdict is unconditional — if one of
-those boots leaves the popup unhealthy or off the view it stored, `make check`
-fails, including when it takes two corrupted fields at once, because the verdict
-is the combined boot and the per-field re-boot that names a culprit can only
-decorate the message. So does a field that gains a floor while its row still
-claims it has none, and so does a field added to `PERSISTED_FIELDS` with no row
-at all. The per-field justification that used to live in the header of
+forward navigation opens, anything behind a click or a timer, and, of what a
+healthy profile reaches, anything beyond its boot onto each view the popup can
+reopen onto. The fields the router does not read share a slot on each boot, so
+one of them truthy while another is falsy is reached only where the falsy slot
+pairs a field that cannot be falsy with one that is. Within that boundary the
+verdict is unconditional — if one of those boots leaves the popup unhealthy,
+`make check` fails, including when it takes two corrupted fields at once,
+because the verdict is the combined boot and the per-field re-boot that names a
+culprit can only decorate the message. The combined boot must also land on the
+view it stored, and each value driven only onto the restore path must land on
+its view, or fall back to Home, as its row declares; a field the router reads
+can legitimately change which view renders, so its own sweep is held to health
+alone. `make check` also fails on a field that gains a floor while its row still
+claims it has none, and on a field added to `PERSISTED_FIELDS` with no row at
+all. The per-field justification that used to live in the header of
 `src/shared/stateSchema.js` shipped a false claim in three consecutive changes,
 each caught only by a reviewer re-deriving thirty fields by hand.