Start at once on a device marked as your own (#395)

* Start at once on a device marked as your own

On a distant link, opening the app waited on four round trips before the
inbox showed: the app page, the session, the folder list, then the folder.

A trusted device now starts from what it kept:

- the service worker answers an app route from its kept page and fetches a
  fresh one behind it; the app checks the server's version at start, and a
  reload for a new build puts the new page in place first, so it is not
  answered with the old one. Assets of the page just replaced are kept one
  build longer for a tab still running it.
- the session's public details, so requests for mail go out before the
  server has confirmed the session; the answer replaces it, and a session
  that has ended lands on the sign-in form as before.
- the folder list and the first page of up to four recently read folders,
  list properties only, so the folders and the inbox paint before any reply
  and the folder query does not wait on the folder list. The "folder no
  longer exists" check still waits for the server's list.

All of it goes through the storage gate: nothing is written or read on a
device not marked as the reader's own, and signing out clears it.

* Show nothing kept before the session is confirmed

Starting from a kept session put the kept inbox on screen before the
server had said the session was still good; a session that had ended
showed mail and then the sign-in form. The spinner stays until the
server answers, as before.

The kept session is gone -- it existed only to start early. The kept
folder list and rows are still applied, from setAccount, which runs once
the session is confirmed: the inbox paints the moment that answer
arrives, and the folder query goes out then without waiting on the
folder list. An unreachable server lands on the sign-in form as before.

FEATURES.md

@@ -1414,8 +1414,13 @@ server settings is deliberately out of scope.
 # Platform
 
 - **Installable PWA** with a service worker: the app shell is cached for
-  installability and fast loads, API requests never are, and navigations are
-  network-first with the shell as fallback.
+  installability and fast loads, API requests never are. An app route is
+  answered from the kept shell at once while a fresh copy is fetched behind it;
+  a shell a build behind is caught by the version check at start and reloaded.
+  After a new version is seen, the rest of its code (composer, settings,
+  viewers) is fetched in the background, so opening them later does not wait on
+  the server; language catalogs are cached when first used, and nothing is
+  fetched ahead when the browser is set to save data.
 - **Manifest shortcuts** for Compose, Calendar and Contacts.
 - **One window, not one per launch.** A `mailto:` link, a shortcut or a
   notification opened while ihasmail is already running arrives in the copy
@@ -1545,15 +1550,23 @@ costs something to get wrong is the one that assumes the machine is yours.
 | --- | --- | --- |
 | Stays signed in | until the browser closes | up to 30 days (`SESSION_REMEMBER_TTL`) |
 | Idle sign-out | after 5 minutes | none |
-| Kept on the computer | nothing | settings cache, recent addresses, username |
+| Kept on the computer | nothing | settings cache, recent addresses, username, and the folder list with the first page of recently read folders (list rows only: sender, subject, preview, flags — no message bodies) |
 | Background notifications | refused | available |
 | Administration | unavailable | available, if the role allows it |
 
 Local storage is gated on that answer for **reads** as well as writes — a
 machine trusted once still has residue, and honoring it would let a previous
 session's data surface in a later untrusted one. Signing out clears the settings
-cache and recent addresses and tears down the push subscription, whichever
-answer was given.
+cache, recent addresses and kept folder list, and tears down the push
+subscription, whichever answer was given.
+
+What a ticked device keeps is what makes it **start quickly on a distant
+link**: once the server has confirmed the session, the folders and the inbox
+paint from the kept copy straight away, and the request for the open folder
+goes out without waiting on the folder list first. The server's answers
+replace the copy a round trip later. **Nothing kept is shown before the session
+is confirmed** — until then the app shows a spinner, so a session that has
+ended goes from the spinner to the sign-in form and never past a mailbox.
 
 The idle timer exists because the alternative does not work: `beforeunload` text
 was removed from browsers years ago, and **no event fires at all** for walking