Handle token expiry and renewal

[iderex]

A token has a lifetime and it will end while a client is running. The session
record in #5 decides whether the core renews ahead of expiry or reacts to a
rejection. This issue implements that decision and proves it.

What this produces

Detection of an expired or rejected token that is distinguishable from a wrong
password and from an unreachable server.

The renewal path, whichever direction #5 chose, with the number of attempts and
the interval bounded and stated.

Exactly one renewal in flight at a time. Twenty tile requests failing at once
must not start twenty renewals, which is the bug that turns one expiry into a
rate-limited server.

Every request that was in flight when the token died either retried once against
the new token or failed with a named error, with no case that silently returns
empty data.

Done when

A test drives the fake server to reject a token mid-run and proves a single
renewal was started for many concurrent failures, and proves each in-flight
request ended in a retry or a named error. Blocked on #5, and on #102, which
decides whether a token is ever refused on the device's own reading of the
clock rather than only on the server saying so.

[iderex]

The clock this issue was waiting on is decided in docs/decisions/0102-the-clocks-every-deadline-is-measured-against.md.

A token is never refused on the device's own reading of the clock. The session ends when the server says so, which arrives as not-authenticated from the vocabulary in #4, and that is the only thing that ends it.

The stated expiry is read on the wall clock and is used for one purpose: scheduling a renewal early enough that the rejection usually does not land in the middle of something a person is watching. Where the device clock is wrong the schedule is wrong, and the cost of that is one extra round trip or one recoverable rejection. Where the stated expiry has already passed by more than the measured skew bound, a renewal may be started before the call rather than after the rejection, and if that renewal is refused the original token is still sent and the server still decides.

The renewal timer itself is an interval rather than a moment, so it is on the elapsed clock: a device that slept through the renewal point owes one renewal on waking, not the sleep.

[iderex]

The renewal path landed as docs/decisions/0034-renewal-and-the-token-generation.md, on 638ed89.

It answers the four things this issue asks for and one it does not name.

Detection that is distinguishable is 0004's kinds rather than an inspection. A token presented and rejected is not-authenticated with the payload saying a token was presented, and that is the only condition that starts a renewal. A wrong password is the same kind with the payload saying none was presented, because at sign-in there is none. A server that did not answer is server-unreachable or timed-out, which say nothing about the token, and treating silence as a rejection is how a connection dropping for ten seconds signs somebody out of a television.

Exactly one renewal in flight is held by a generation number on the session rather than by a flag. Every request records the generation of the token it went out under, and a rejection is acted on only where it names the generation the session still holds. Twenty tile requests rejected in the same instant name the same generation, so the first starts a renewal and the rest wait on its outcome. A flag would answer the question "is one running now", and the question that has to be answered is "has the token I was rejected under already been replaced", which is the one a late rejection needs.

Attempts and interval. One renewal per rejection, never a loop, which is 0005's rule kept rather than reopened. A rejection of the post-renewal retry starts nothing further. The renewal request is itself an ordinary request, so 0038 bounds it at three attempts inside five seconds, and those are attempts at one renewal rather than three renewals. The schedule ahead of expiry fires at the later of the stated expiry less five minutes and the halfway point of the stated lifetime, on the elapsed clock 0102 fixes; the halfway rule is there so a token stated to last two minutes is not scheduled for renewal before it was issued.

Every in-flight request ends in a retry against the new token, a not-authenticated, or the transport's own kind, and nothing anywhere in the path returns an answer with no items in it.

The thing this issue does not name and the record decides is what a renewal that nothing answered does. A refusal signs the session out. A silence leaves the session and its token exactly as they were, and the waiting calls fail with the transport's kind. Written the other way, which is one branch for a renewal that produced no token, the code is correct wherever the server is reachable and deletes a working session on a train, where the recovery is a sign-in on an on-screen keyboard rather than a retry.

Whether the server offers a renewal route at all is part of the surface #10 owns. The record is written for both answers rather than waiting for one, and where there is none the first rejection ends the session and the sign-in routes in #30, #31 and #32 are not re-run on a person's behalf.

Both conditions here are unchanged. Driving the fake server to reject a token mid-run, proving a single renewal for many concurrent failures and proving each in-flight request ended in a retry or a named error are statements about running code.