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.

CLAUDE.md

@@ -62,7 +62,7 @@ Location: `~/.config/terdut-tui/config.yaml`
 
 ```yaml
 server_url: https://terdut.example.com
-api_key: <64-char hex key>
+username: niklas      # optional, prefills the sign-in form
 refresh_interval: 30  # seconds, optional, default 30
 theme: gruvbox-dark   # optional, default gruvbox-dark
 team: Ops             # optional, team name or id to start on, default all
@@ -72,7 +72,14 @@ Built-in themes are `gruvbox-dark` and `gruvbox-light`; user themes are YAML
 files in `~/.config/terdut-tui/themes/`, optionally `extends:`-ing a built-in.
 See the README for the token list.
 
-The API key is a one-time secret generated by terdut-server (`POST /api/users/{id}/api-keys`).
+There is no API key in the config. The TUI signs in as a user (`POST /api/login`, the
+same session cookie as the web UI) and `internal/session` keeps the token in
+`~/.config/terdut-tui/session.json`, mode 0600, keyed by server URL. The client
+attaches `terdut_session` itself rather than using a cookie jar, because a jar drops the
+server's Secure cookie over plain http. It must never send `Authorization` as well: the
+server judges a request with that header on it alone. A 401 from anything (`msgError`
+in `update.go`) returns to the sign-in form and clears `Model`. A user with no password
+cannot sign in, and the server answers it like a wrong one, so the form says so.
 
 ## Running
 
@@ -105,6 +112,7 @@ go build -ldflags="-X main.version=v0.1.0" -o terdut-tui .
 | 5 | User management and API key lifecycle |
 | 6 | Incidents: queue, timeline, ack/assign/snooze/resolve, MTTA/MTTR |
 | 7 | Teams: `T` switcher, per-team schedule, admin/disabled markers (server v0.20) |
+| 8 | Sign in as a user instead of an API key (server v0.10+ session cookie) |
 
 <!-- graymatter:instructions:begin — managed by `graymatter init`; edits inside this block are overwritten -->
 ## Memory (GrayMatter)