Sign in as a user instead of with an API key

The web UI signs in with a username and password and holds a session
cookie; the TUI was the only client still needing an API key pasted into
a config file. It now asks for the same credentials on a form at start.

What is kept between runs is the session token, not the password, in
session.json under the config directory, mode 0600 and keyed by server
URL so one server's token is never offered to another. It resumes on the
next start; the server's sessions last 30 days and slide with use. L
signs out, which ends the session on the server and deletes the saved
one even if the server cannot be reached.

The client attaches the cookie by hand instead of using a cookie jar:
the server marks it Secure behind https, and a jar drops a Secure cookie
it is given over plain http, which would break a local server for no
reason. It sends no Authorization header at all, since the server judges
a request carrying one on that alone and never falls back to the cookie.
Writes go through the server's cross-origin guard, which lets a client
that sends neither Origin nor Sec-Fetch-Site through; checked against a
real v0.20.1 server for both reads and writes.

A 401 from anything means the session is gone (expired, ended from the
web UI, or the account disabled), so the TUI returns to the form with the
reason, forgets the saved token, and drops what the last session loaded
rather than showing it to whoever signs in next. A 403 is a permission
and leaves the session alone. The refresh timer is started once, so
signing out and in does not leave two running.

An account with no password cannot sign in, and the server answers it
exactly like a wrong password, so the form's message says a password
must be set first. Users created only for API access hit this.

Breaking: api_key in config.yaml is no longer used. It is not an error
to leave it there; the form says it is ignored. API keys still exist on
the server and k in Users still manages them.

README.md

@@ -85,13 +85,31 @@ Create `~/.config/terdut-tui/config.yaml`:
 
 ```yaml
 server_url: https://terdut.example.com
-api_key: <your-api-key>
+username: niklas      # optional, prefills the sign-in form
 refresh_interval: 30  # seconds, optional
 theme: gruvbox-dark   # optional, this is the default
 team: Ops             # optional, a team name or id to start on; default is all
 ```
 
-The API key is generated in terdut-server. See the server documentation for how to bootstrap a user and issue an API key.
+## Signing in
+
+The TUI signs in the way the web UI does: with a user account's username and
+password, on a form shown at start. It keeps the server's session, not the
+password, in `~/.config/terdut-tui/session.json` (readable by you only), so the
+next start resumes it. The server's sessions last 30 days and slide with use.
+When it has ended, or the account is disabled or the session is ended from the web
+UI, the TUI returns to the form and says so. `L` signs out, which also ends the
+session on the server and deletes the saved one.
+
+The account needs a password, since that is what signing in uses. A user
+created only for API access has none and cannot sign in: the server answers it
+exactly like a wrong password. Set one in the web UI, or have an administrator
+press `p` on that user in Users. Too many failed attempts are rate limited by
+the server for a few minutes.
+
+> **Upgrading from v0.10.0 and earlier:** `api_key` in `config.yaml` is no longer
+> used. Remove it and sign in. API keys still exist on the server, and `k` in
+> Users still manages them, for whatever else uses them.
 
 ## Themes
 
@@ -152,6 +170,7 @@ Global:
 | `esc` | Go back |
 | `r` | Refresh |
 | `f` | Cycle filter |
+| `L` | Sign out |
 | `T` | Switch team: all → each of your teams (when you have more than one) |
 | `q` | Quit |