Prove that nothing secret is ever written to the cache

[iderex]

The session record in #5 and the cache contract in #6 both say it. A sentence in
a document is an explanation of a rule. This issue is the machine that refuses
the violation.

The failure this prevents is concrete. A token in a cache file is a token
readable by anything else on the device that can read files, it survives sign-out
unless somebody remembered to clear it, and it is the kind of thing that is found
by somebody else after it has been true for a year.

What this produces

A test that drives a full session lifecycle through the core with a recording
storage implementation, then searches everything written for the token, the
password, and any other secret in play, and fails if any of them appears.

The same search over everything the core logs at its most verbose setting.

A test that signs out and proves nothing sensitive survives.

Done when

The tests exist, and each of them is proven to bite by a deliberate change that
writes a secret and reddens exactly that test and no other. Blocked on #33, #40,
#41 and #101.

[iderex]

Two of the three searches this issue asks for name a surface that landed records have decided will not exist, and one of them changes what the test is rather than where it runs. Read at b35aee1d376ba7b4139c08ddd90d19b642c48ec0.

There is no log to search. docs/decisions/0003-what-the-core-does-not-do.md refuses one by name:

git show origin/main:docs/decisions/0003-what-the-core-does-not-do.md | sed -n '126,132p'
### Diagnostics leave the core as events, not as text

The core produces diagnostic events with identities and fields. Where they go,
whether they are written down, and whether anything is shown to a person are the
client's, behind the interface in #100. A core that logs has chosen a destination
on a platform it does not know, and on a shared device it has written to a place
it cannot promise is private.

docs/decisions/0100-the-diagnostics-interface.md carries that to its shape. Everything the core has to say leaves as an event handed to a client's sink, with fields as data and never a rendered sentence, and the most verbose setting is the detail severity in its closed set of four. So the second search is over every field of every event that reaches a collecting sink with the level at detail, and a search written against a file or a stream of text passes by finding nothing to read.

The first search is in the same position for a different reason. docs/decisions/0071-what-may-leave-through-a-diagnostic-event.md excludes the token and anything derived from it, the password, and whatever the store in 0033 handed back, at every severity with no configuration that admits them, and excludes any field nobody has classified. So the event surface is one where a secret is absent by construction, and a search over it proves that the exclusion was implemented rather than sampling for a leak. That is worth having and it is a different test from the one this issue describes, because the thing it can fail on is a field that was classified wrongly or not at all, not a value that slipped through a filter.

The cache surface is the one where the search reads as written, since the store in 0040 takes whatever bytes it is handed and 0041 builds a name for them, and nothing in either refuses a token on the way past.

One more thing worth having before this is built rather than after. The third bullet asks for a sign-out that proves nothing sensitive survives, and docs/decisions/0114-signing-out-and-forgetting-a-server.md splits that across two acts: a sign-out drops the token from memory and forgets the secret through 0033, and the cache entries go on the second act, forgetting a server, because 0006 and 0068 keep them deliberately. So the sign-out half of this issue is about the token and the secret, and an entry still readable afterwards is that decision rather than a leak.