Docs and site: who pays for Signals, and Signals in the API reference (#271, #269)

docs/signals.md says what the admin's setting does and that a key is
checked before it is saved; the install guide lists TYPESAFE_KEY; the API
reference has Signals' routes and types and the new fields of Me and
Settings; the home page says an admin may provide the key.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/signals.md

@@ -6,13 +6,21 @@ mean (#259). TypeSafe's Jev reads each item of the feeds they subscribe to and p
 about that subject: the name, the words and the sentence together, not any one word. Those items show in the Signal as well as in their
 own feed. The rest stays noise, where it was.
 
-Each person brings their own TypeSafe key, entered in Settings. Nothing is judged for someone
-without one. Jev is asked once for each item, on that person's key, with one question for each of
-their Signals that has not heard about the item yet.
+Whose TypeSafe key pays for Jev is the admin's choice (#271), under Admin, Server, **Signals for
+everyone, on this server's TypeSafe key** (`signals_on_server`):
+
+- **On**, with the server's key in `TYPESAFE_KEY`: everyone has Signals, with nothing to set up.
+  Every item is asked about on the server's key, and keys people saved are kept but not used.
+- **Off**, the default, or on with no `TYPESAFE_KEY`: each person turns Signals on in Settings
+  with a key of their own. Nothing is judged for someone without one, and their Signals folder is
+  not shown.
+
+Jev is asked once for each item, on that key, with one question for each of the person's Signals
+that has not heard about the item yet.
 
 ## What someone sees
 
-- **The sidebar.** A Signals folder comes first in the feed list, under All Subscriptions (#255,
+- **The sidebar.** Once Signals are on for someone, a Signals folder comes first in the feed list, under All Subscriptions (#255,
   #256). It is closed or open as an OPML's folder is, remembered in each browser. Its row is like
   any folder's (#265); New signal is the + on the folder's page. Inside the folder are the
   person's Signals, each with its items and unread counted under its name.
@@ -24,13 +32,17 @@ their Signals that has not heard about the item yet.
 - **Each Signal's row** says "12 items · 3 unread", as a feed's row counts its own.
 - **The folder's page** lists the Signals, as an OPML's page lists its feeds, with the + for a new one.
 - **A Signal's page** is an ordinary item list: All, Unread, Downloaded and Pinned, search and sort.
-  Its header says what it listens for (the sentence, or the words), and that nothing is picked
-  out without a key. Edit changes the name, the words or the sentence; Delete removes the Signal
+  Its header says what it listens for (the sentence, or the words), and, on people's own keys,
+  that nothing is picked out without one. Edit changes the name, the words or the sentence; Delete removes the Signal
   and leaves the items in their feeds.
 - **Read state is the item's.** Reading an item in a Signal reads it in its feed, and the other way
   round. The counts follow without a reload (#258).
-- **Settings, TypeSafe key.** A password field. A key saves on leaving the field, and the bin
-  forgets it. The key is never sent back to the page, which only learns whether one is set.
+- **Settings, Signals.** On the server's key, a line saying the server pays. On people's own, a
+  Signals switch: turning it on shows a password field for the key, which saves on leaving the
+  field once TypeSafe has taken it (one short question on that key); a key TypeSafe refuses is
+  not saved, and the page says so. Turning the switch off, or the bin, forgets the key and hides
+  the folder; the Signals are kept. The key is never sent back to the page, which only learns
+  whether one is set.
 
 ## How an item gets into a Signal
 
@@ -94,7 +106,7 @@ Questions in one call are judged independently and in parallel.
 
 ### A request
 
-Sent with `Authorization: Bearer <the person's key>`, for an item and two of their Signals:
+Sent with `Authorization: Bearer <the key>`, the server's or the person's, for an item and two of their Signals:
 
 ```json
 {
@@ -155,7 +167,8 @@ missing from the answer is left unjudged and asked again next pass.
 
 | TypeSafe answers | What the judge does |
 |---|---|
-| 401, 402, 403 | The key is refused. That person is passed over until they save a key or the daemon restarts, so a bad key is not sent the whole queue. Logged once: "TypeSafe refused a Signal key". |
+| 401, 402, 403, on the server's key | Everyone's key is refused. The pass ends and the queue waits for the next one, five minutes on. Logged: "TypeSafe refused the server's key for Signals". |
+| 401, 402, 403, on a person's key | The key is refused. That person is passed over until they save a key or the daemon restarts, so a bad key is not sent the whole queue. Logged once: "TypeSafe refused a Signal key". |
 | 400, 422 | The request itself is wrong, so every item's would be. The pass ends; the items wait for the next one. Logged: "TypeSafe refused a Signals request as malformed", with TypeSafe's reason. |
 | anything else, or no answer | That item is left unjudged and asked again next pass. Logged: "Jev could not judge an item". |
 
@@ -238,9 +251,18 @@ anywhere else.
 { "typesafe_key": "ts_…" }
 ```
 
-A string saves the key and lets the judge try it again. `null` or an empty string forgets it. A
-key is up to 500 printable characters. `GET /api/me` says `"typesafe_key_set": true` and nothing
-more.
+A string is checked with TypeSafe, by one short question on that key, then saved, and the judge
+tries it again. `null` or an empty string forgets it. A key is up to 500 printable characters.
+A key TypeSafe refuses is a `400` ("TypeSafe did not accept that key") and not saved; TypeSafe not
+answering is a `502`, and the key is not saved either. `GET /api/me` says `"typesafe_key_set":
+true` and nothing more about the key, and `"signals": "server"` or `"own"`, whose key is used.
+
+### `PATCH /api/settings`, who pays
+
+An admin's `{ "signals_on_server": true }` judges everyone's Signals on `TYPESAFE_KEY`, and
+`false` on each person's own. `GET /api/settings` has `signals_on_server` and
+`typesafe_server_key`, whether the server has a key to use; without one the setting changes
+nothing. A change wakes the judge and lets keys refused before be tried again.
 
 ### `POST /api/signals/icon`