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

The check that every swept field is driven both truthy and falsy now
counts only `hostile` and `falsy` values; a `hostileRestore` value
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 now names its views and declares whether
the boot lands on them or falls back to Home, and the test asserts it,
so an entry that stops reaching its renderer goes red.

The file's 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.