Derive every key from the signing key in one place (closes #315)

seal.DeriveKeys derives the session hash and block keys, the encrypted URL
key and the CSRF key from the signing key, with their salts declared beside
it, and returns them as one seal.Keys. internal/providers calls it once at
startup and provides the value to the fx graph. The session manager, the
encrypted URL generator and the CSRF protection each take their own key.
session.NewManager, encurl.NewGenerator, newCSRFProtect and handlers.New
return no error, as nothing in them can fail now. Each key is derived as
before, with seal.DeriveKey and the same salt. The signing key itself stays
the HMAC key of signed URLs and the login password. README.md says under
signing_key what it protects.

Model: opus-5-5

README.md

@@ -765,7 +765,17 @@ Key settings in more detail:
   duration; default `60s`. The upstream fetch counts toward it, and so do the
   waits for an upstream connection and for a processing slot (up to 10 seconds
   each), so keep it longer than `upstream_fetch_timeout` plus 20 seconds
-- `signing_key` — HMAC secret for URL signatures
+- `signing_key` — the secret that protects signed URLs, encrypted URLs and
+  logins. pixa uses it as it is for two things:
+    - the HMAC key of signed URLs (see Signature Specification)
+    - the password of the login page
+
+    pixa derives every other key it uses from it at startup, with HKDF-SHA256:
+    - a key that signs the session cookie
+    - a key that encrypts the session cookie
+    - a key that encrypts the token of an encrypted URL
+    - a key that signs the CSRF token cookie of the login and generator pages
+
 - `db_url` — the SQLite database to open; omitted, it is
   `file:<state_dir>/state.sqlite3?_pragma=journal_mode(WAL)`, which keeps the
   database in WAL mode. `state_dir` is percent-encoded in it, so a `%`, `?` or