Make cold start serve something before the first network reply

[iderex]

The published number is a usable tile in under 1.2 seconds from a cold start.
That budget is spent before the process has a session, and a core that must
complete a sign-in round trip before it can answer anything has already spent
most of it on a slow connection.

What this produces

A start-up path that reads the cache before, and independently of, restoring the
session, so that a client can draw from cache while authentication is still in
flight.

A stated list of what is available at that point and what is not, since a cached
list is safe to show and a cached playback authorisation is not.

Measurement points at both ends of that path, feeding the harness in M7, so the
claim is a number rather than an intention.

Done when

A test starts the core with a populated cache and an unreachable server and
proves a library list is served without any successful network call. The path is
instrumented with the measurement points named in #8. Blocked on #8, #40, #43.

[iderex]

The ordering and the list landed as docs/decisions/0046-what-is-served-before-a-session-is-restored.md, on 393949e.

The part that took the work was establishing that this path is reachable at all, because the natural reading is that a cache read needs a session and a session needs a sign-in. It does not. 0033 has no listing, so a client restoring a session at start already holds the server, the account identifier and the device identity itself and hands them over to name the secret it wants read. 0041 builds a key out of a version tag and those same three parts plus the request, and 0006 keeps the token out of every one of them. So every input a key needs is in the client's hands before the core has touched a keychain or a network, and the account identifier is a value kept from the last sign-in rather than one this start has to earn. The cold start serves from cache because the key space is addressable without a secret, not because a step was skipped.

The ordering is the sentence the record exists to make refusable. The cache read is not sequenced behind the secret read. 0033 already names the case that decides it: a device locked at the moment of a background start fails the secret read rather than answering it, and a start ordered the other way then shows nothing while a complete answer sits in the store, on the device where the network is most likely to be absent as well.

The stated list this issue asks for came out as two lists rather than one. Everything 0006 caches is servable that early, under 0043's three states, with no exception carved for this path. What is not servable is a list of calls rather than of entries: a playback handover in #111, any write toward the server including a position report, a read that demands freshness, and sign-in itself. The case this issue names as the one to be careful about, a cached playback authorisation, turns out to have been answered before the record was written, since 0006 does not cache one. There is no entry to withhold, and the record says that this came from the cache contract rather than from a rule on this path, because a later change that cached anything derived from a token would break the section without touching it.

One thing the issue does not name is decided there. A cache read never moves a session's state, so a screen full of library is not evidence that anybody is signed in, and the session state is read on its own under 0009. The boundary is stated in the same place rather than implied: naming a session is the act that exposes that session's cache, that act is the client's, and 0041 keeps two accounts on one device apart while doing nothing to keep one account's entries from whoever picked the device up.

No new measurement endpoints. 0008 already opens the core's interval at the call issuing the first library query after creation and closes it at the first decoded artwork bitmap in that answer, and separates an empty-cache variant from a warm-cache one. This path is that warm-cache variant, so the points this issue asks for are pointed at rather than named a second time.

Both conditions here are unchanged. A test that starts the core with a populated cache and an unreachable server and proves a library list is served with no successful network call, and the path instrumented with 0008's points, are statements about running code, and this tree has nothing to assert them against. This stays open on both.