Implement the slow-server behaviour, reporting progressively rather than at the end

[iderex]

The record in #7 fixes the thresholds. This is where they become behaviour a
client can build on. The property that matters is that a caller learns something
true at 300 ms rather than learning nothing until a timeout.

What this produces

A request that reports as it goes: it started, a cached answer is available, the
answer is late, the answer is not coming. The exact stages and their thresholds
come from #7.

The cached answer offered first where one exists, without cancelling the network
request, so that a screen fills immediately and corrects itself.

Every stage carrying enough for the client to draw something honest without
guessing at what is happening.

Done when

A test drives the fake server at several delays and asserts the exact sequence
of stages for each, including the case where a cached answer exists and the
case where none does. Blocked on #7, #21, #27, #43, and on #102 for the clock
the stage thresholds are 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 stage thresholds are on the steady clock. Each one is an interval between the moment the request went out and now, both inside one run, so it is a duration and not a moment, and a wall-clock correction part way through a slow request must not move a stage boundary.

The steady clock rather than the elapsed one puts a suspension outside the measurement, which matches what a suspension does to the request itself: there is nothing in flight to be slow.

The age carried alongside a cached answer while a fresher one is outstanding is a different quantity and is not on this clock. That is a cache entry's age, anchored on the server's own stated time, and #43 owns it.

[iderex]

All three of the things this issue asks to produce are already fixed in the record for #7, so what is left here is one test rather than a record and a test. Read at e5a513c23f9bc6a0ddedc7b52bb299ae5d0cee05.

The first bullet asks for a request that reports as it goes, with the stages and thresholds taken from #7. That record does not stop at the thresholds. It fixes the moment each report is made and what each one carries:

git show origin/main:docs/decisions/0007-a-slow-server-and-a-server-that-is-gone.md | sed -n '86,97p'
## What the core reports, and when

At the moment a request is made: which session it belongs to, whether the core
already has a cached answer for it, and the age of that answer if it does. This is
reported before any byte leaves the machine, so a client has something truthful to
draw at nought.

At 400 ms, if the request is still outstanding: `late`, with the age of the cached
answer if there is one. Nothing about the request has gone wrong and the core says
nothing that implies it has.

At 5 seconds: `abandoned`, with the vocabulary member from #4 that names a request

The second bullet asks that a cached answer be offered first where one exists, without cancelling the network request. The same record makes that the default rather than something a caller selects, and names the request shape it belongs to:

git show origin/main:docs/decisions/0007-a-slow-server-and-a-server-that-is-gone.md | sed -n '110,115p;120,122p'
## What is served from cache while a request is outstanding

Everything the cache holds for that session, marked with its age. Serving it is the
default rather than something a client opts into, because #46 requires the core to
serve something before the first network reply and a cache that only answers after
the network has failed cannot do that.
Whatever is available soonest. The core answers from cache if it has anything,
marks the age, and reports the network states above as the request ages. This is
the request a screen makes.

The third bullet asks that every stage carry enough for a client to draw something honest without guessing. That section is there as well, and it is written as what a client can know at each moment rather than as what the core should say:

git show origin/main:docs/decisions/0007-a-slow-server-and-a-server-that-is-gone.md | sed -n '157,160p'
## What a client can put on screen, derived

The core supplies no wording. What follows is what a client can know at each
moment, which is what it needs in order to write its own.

So no record is owed on this issue. Writing one would put a second copy of the sequence and the thresholds in the tree, and the second copy is the one a later reader trusts. 0007 already reaches in this direction from its own side, in the alternative it refuses:

git show origin/main:docs/decisions/0007-a-slow-server-and-a-server-that-is-gone.md | sed -n '217,219p'
Reporting only at the end of a request. Half the interface and none of the
progressive behaviour #44 requires. It also makes the 1.2 second number
unreachable by construction, because nothing can be shown until something has

What remains is the condition, and it is one test with nothing under it. Driving the fake server at several delays and asserting the exact sequence of stages, with a cached answer present and with none, is a statement about running code, and there is no build here to assert it against:

git ls-tree -r --name-only origin/main | grep -Ev '^(\.github/|docs/)'
.gitattributes
DCO
NOTICE.md
README.md

git ls-tree -r --name-only origin/main \
  | grep -E 'go\.mod|Cargo\.toml|package\.json|pom\.xml|CMakeLists\.txt|\.csproj$|\.sln$|pyproject\.toml|build\.gradle'
echo "exit=$?"
exit=1

The list of blockers in the body is therefore wider than what this issue actually waits on. #7 is 0007, #27 is 0027, #43 is 0043, and #102 is answered in the comment above. #21 is the one that has not landed, and the fake server is what the several delays are driven from.