Let people set their own ntfy topic under Account

The first-run checklist's first step is "Set where your pages go", and its
button navigated to /more — which had no field for it. Every new user was
sent to a page that could not do the thing it sent them there for, and the
only ways to actually set a topic were curl or asking an administrator.
That has been true since the checklist shipped in v0.15.0.

Account now has a Notifications section above the password form: the topic,
prefilled and saved through the endpoint that already existed, and a Send a
test push button. The test is offered only once a topic is saved, because
it publishes what the server has stored rather than what is half-typed in
the field, and a button that silently tested the previous value would be
worse than no button.

Saving assigns the response to state.me.user, so the checklist stops asking
and the test button appears without a reload. Clearing works by saving an
empty topic: the server treats that as "no topic of their own" rather than
an error, and returns a user with ntfy_topic absent — it is omitempty — so
the form reads the cleared state from the response rather than assuming it.

The copy says the topic is a shared secret, because people reach for their
own name and it is the only thing between a stranger and their pages. Same
reason the topic stays out of an incident's timeline, which every API key
can read.

No server change: PUT /api/users/{id}/notify has been self-or-admin since
#3 and needed nothing. Only the ntfy topic is per-person — the server is
the install's one TERDUT_NTFY_URL and is not something a user picks.

Also drops a line on that page still sending people to terdut-tui for user
management, which stopped being true one release ago.

Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7

README.md

@@ -47,8 +47,8 @@ curl -H "Authorization: Bearer $KEY" http://localhost:8080/api/users
 
 The server serves a web UI at `/`: the incident queue, each incident's alerts
 and timeline with every action (acknowledge, assign, snooze, note, resolve,
-archive), who is on call, the alert feed, and changing your own password. It is
-built for a phone first. On a phone it has a bottom tab bar and a sticky action
+archive), who is on call, the alert feed, and an *Account* tab for your own
+password and the ntfy topic your pages go to. It is built for a phone first. On a phone it has a bottom tab bar and a sticky action
 bar, it follows the system's dark mode, and it can be added to the home screen.
 From 900px wide it switches to a sidebar with the queue and the incident side by
 side. Statistics remain in
@@ -351,10 +351,20 @@ exactly as it was rather than with a hole in it.
 ### Push notifications
 
 With `TERDUT_NTFY_URL` set, an incident that opens is pushed to the on-call
-person's phone through [ntfy](https://ntfy.sh). Set each user's topic with
-`PUT /api/users/{id}/notify`; a user with no topic falls back to
-`TERDUT_NTFY_FALLBACK_TOPIC`, as does an incident that opens with nobody on call.
-If neither yields a topic, nothing is queued.
+person's phone through [ntfy](https://ntfy.sh). Everybody sets their own topic
+under *Account* in the web UI, where a **Send a test push** button proves it
+before an incident has to; `PUT /api/users/{id}/notify` is the same thing over
+the API, and an administrator may set somebody else's. A user with no topic
+falls back to `TERDUT_NTFY_FALLBACK_TOPIC`, as does an incident that opens with
+nobody on call. If neither yields a topic, nothing is queued.
+
+The **server** is the install's one ntfy, from `TERDUT_NTFY_URL`, and is not
+something a user picks. Only the topic is per-person.
+
+A topic is a shared secret with the ntfy server: anyone who knows it can both
+read the pages and publish to it, so an unguessable one is worth the trouble.
+That is also why the topic never appears in an incident's timeline, which every
+API key can read.
 
 Three things get pushed: