Implement the absent-server behaviour and the way back

[iderex]

A server that is gone is a different condition from a server that is slow, and it
has a recovery the core can drive on its own rather than making the client poll.

What this produces

The state the core reports when the server is unreachable, distinct from every
slow state.

What is still available: everything cached, marked with its age, so that a client
can show a real library that says plainly it is not current.

The recovery. The core retries on its own schedule, bounded, and reports when the
server answers again, so the client does not have to poll or ask a person to pull
to refresh.

What a write attempted while the server is gone does, which is the queue in #47.

Done when

A test takes the fake server away and proves cached content is still served
with its age, proves the unreachable state is distinct from every slow state,
and proves the core reports recovery by itself when the server returns. Blocked
on #7, #43, and #102 for the clock the wait before a recovery attempt is
measured against.

[iderex]

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

The wait before a recovery attempt is on the elapsed clock. It is a duration rather than a moment, so it is on one of the two monotonic clocks, and the question the record asks next is whether the interval has to survive a suspension. This one does. The wait is real time and it keeps running while the device sleeps, so a device that was away for an hour has waited an hour and is due an attempt when it wakes rather than starting its wait again.

The steady clock is wrong here for the same reason it is right for a request timeout. A suspension takes the request away and there is nothing left to time out, and it does not take away the fact that the server has been unreachable for as long as it has.

The cached content this issue still serves while the server is gone carries an age, and that age is a different quantity on a different anchor. It is measured against the server's own stated time rather than against any of the three clocks, because it has to survive a restart, and #43 owns it.

[iderex]

The schedule landed as docs/decisions/0045-the-recovery-schedule.md, on 7ee108e. The clock the wait is measured against is settled in the comment above and the record reads it rather than restating it.

What this issue was left holding was a number two other records point at and neither can supply. 0007 says the core attempts the server again on its own bounded schedule and stops when the bound is reached, without saying what the bound is. 0038 says the delay 0004's retry column refers to for server-unreachable is this schedule. Following either arrives here.

The schedule is two seconds before the first probe, doubling to a ceiling of five minutes, with the same random spread 0038 applies to its retry waits, per server. Two seconds because the evidence for the declaration was either an immediate refusal or two abandoned requests and neither becomes false within a second, and because the commonest cause on a home network is a router that dropped a connection for a moment. A ceiling because doubling without one reaches intervals where the core is not really probing, so a server fixed at midday is noticed in the evening and the person concludes the application does not recover at all. The spread matters more here than in 0038, since eleven clients on one household network declared unreachable by one router restart would otherwise probe in step forever. Each number is chosen rather than measured, and the harness in #65 is where measured replacements would come from.

The bound is an hour of continuous unreachability, after which the core stops probing and says it has. There is a bound because a probe is a network call on a device somebody is carrying, and a core that probes for as long as the process lives keeps a radio busy on a phone in a bag overnight for a server switched off the previous evening, at a cost invisible to whoever would have to diagnose it. An hour rather than a count of attempts, because a count changes meaning every time the schedule does while what is being bounded is how long the core spends on a server that is not answering.

Giving up discards nothing. The queue in 0047 keeps every entry and never expires one, cached entries keep their ages under 0043, and the session is untouched. The core has stopped asking and that is all it has stopped doing. What restarts it is any request a client makes, and a request made after somebody pulled a screen down is a better trigger than any timer.

One thing was added rather than decided from the issue's list, and it is the cheaper way back. A client may tell the core to attempt now. The core cannot know whether the device just joined a network or came off aeroplane mode, because 0003 refuses it platform knowledge, and that is exactly what a client is holding. The call is advisory, it does not promise the server is there, and the schedule remains what covers the case where nobody passes it on.

What a recovery does besides being reported is the other half. The queue drains, and nothing else happens. Nothing is refetched, because the core does not know what a client is showing and refetching spends the connection of somebody who has just got one back; a client showing a stale list already knows it is stale, since 0043 gives it the age with every read. Nothing is invalidated, because a server coming back is not evidence that anything changed while it was away, and treating it as such turns every brief outage into the cold start #46 exists against. The recovery is reported twice over, as an event through 0100 and as a state readable through a call that cannot wait, so a client that was not listening at that moment is not left behind.

All three conditions here are untouched. Taking the fake server away and proving cached content is still served with its age, proving the unreachable state is distinct from every slow state, and proving the core reports recovery by itself are statements about running code. There is no language chosen, no build and no test command in this tree, and #21 is open. This stays open on all three.