Handle a token that dies during playback

[iderex]

The kickoff names this case specifically. It is the one where a wrong answer is
most visible, because something is on screen and a person is watching it.

The rule the record in #5 has to have fixed, and this issue implements: playback
that has already started does not stop because a report failed.

What this produces

The stream in flight left alone while renewal is attempted.

Position reports queued rather than discarded, so that the position reached
during the renewal is not lost, which connects to the offline queue in M6.

A single named event the client can react to when renewal fails and a person has
to sign in again, arriving early enough that the client can decide when to
interrupt rather than being interrupted.

What happens when renewal succeeds: the queued reports go out in order, and
nothing is reported twice.

Done when

A test plays through a token death against the fake server and proves the stream
was not stopped by the core, the position reached during the outage arrives at
the server after renewal, and nothing is reported twice. Blocked on #34.

[iderex]

The record this issue named as its blocker landed as docs/decisions/0034-renewal-and-the-token-generation.md, and with it the sequence in docs/decisions/0005-the-session-model.md, whose mid-playback section names this issue as where it is implemented. So what is left here is the test rather than a decision, and one of the three conditions does not describe something this core can be asked about. That is worth settling before somebody writes it.

Proving the stream was not stopped by the core reads as an observation of a stream. There is no stream in the core to observe. 0005 says it for this exact case: the stream is read by the platform's player against the address handed over in #111, and the core does not have a way to stop it, does not want one, and would be wrong to use one. 0112 draws the same line from the other side, with decode and the presentation of decoded frames reached through each platform's own interface and written nowhere in this project. A run against the fake server sees the core's own requests and never the bytes somebody is watching, so a test asserting the core did not stop the stream asserts the absence of a route rather than the presence of a behaviour, and a test that cannot fail is the guard this repository refuses everywhere else.

What is observable in its place, on the same run, is the core's own output while the token dies. No cancellation is delivered. No outcome arrives on a call the client did not make, which 0005 states as the reason the client hears nothing except through diagnostics at that moment. Nothing already in the queue is discarded, which 0005 requires because an authentication failure says nothing about whether the positions are correct. On the success branch the queue drains in order and the current position is reported. Each of those is a statement about something the core hands out, and each of them fails if the code takes the shape 0005 was written against.

The second and third conditions stand as written, with one thing worth naming about the third. Nothing being reported twice is not a property this path establishes. 0047 makes every queued action an assertion of a desired state, so delivering it twice is the same as delivering it once, and that holds whether or not a token died. What a test here shows is narrower and is the part that can go wrong: that a rejection during playback puts its report on that queue rather than around it, and that renewal does not send one report and then queue another for the same target.

All three conditions are untouched, and this stays open on them.