feat(rust): Admin → Rust servers page and the next wipe on the web (phase 16)

The module had no page for its own server rows: they were written only
through PUT /admin/rust/servers/:id, and the README described an
"Admin → Rust" server form that did not exist. D133 (org lead) builds it:
add, edit, test and delete a server, with the D130 wipe schedule in the
same form. The token stays write-only and an edit sends the stored
protocol back rather than re-stamping the row.

The next wipe shows on the server list and in the server page's header,
in the reader's own clock, marked "rescheduled" for a one-off date.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

README.md

@@ -43,11 +43,13 @@ rows here; the website core never learns there is more than one.
 | Public | `GET …/servers/:id/clans` — the server's clans, best score first (public: names nobody) |
 | Public | `GET /api/v1/public/rust/clans/:externalId` — one clan, and its roster inside the roster audience |
 | Player | `GET /api/v1/player/rust/servers` — the server list, on the authenticated tier |
-| Admin | `GET/PUT/DELETE /api/v1/admin/rust/servers` and `POST …/:id/test` |
+| Admin | `GET/PUT/DELETE /api/v1/admin/rust/servers` and `POST …/:id/test` — the `PUT` carries the wipe schedule |
 | Admin | `GET/PUT /api/v1/admin/rust/visibility` — who may see who is online, fleet-wide and per server |
 | Pages | `/rust` — the server list, and the module's landing page |
 | Pages | `/rust/servers/:id` — one server: feed, leaderboard, who is on, wipes, clans |
 | Pages | `/rust/clans/:externalId` — one clan, with core's Team notify, activity and forum in three module slots |
+| Pages | `/admin/rust/servers` — add, edit, test and remove servers, and set each one's wipe schedule |
+| Discord | `/status`, `/wipe`, `/top`, `/online`, `/clan` — read-only, answered from this module's tables |
 | Teams | The deployment's Team provider: a first-party Rust clan is a Team |
 | Slot | `site.footer.status` — a live server/player count in core's footer |
 
@@ -73,8 +75,18 @@ at most 100 clans per server, and a server at that ceiling answers core partiall
 removes a Team on its word. Core holds one Team provider per site, which is one reason **a site runs
 one module**: core's installer refuses a second.
 
-The rest of the module — notifications,
-events, the live map, Discord commands — arrives phase by phase. **Nothing is registered before it
+**The next wipe is the operator's to state** (Admin → Rust servers): a rule — the monthly forced
+wipe only, weekly or every other week, each in the server's own time zone and always including the
+forced wipe (first Thursday, 19:00 UK time) — plus an optional one-off date that replaces the next
+computed wipe. It is computed on every read and never stored, so it cannot go stale after a wipe.
+The server list, the server page, the Android app and `/wipe` all show it.
+
+**The Discord commands answer from the tables, never from a game server**, inside core's three-second
+budget. Every refusal is private. **An answer narrower than public goes to the caller alone:** a
+moderator's `/online` in a public channel shows the names to the moderator, never to the channel, and
+the same for a clan roster. Everything else is posted where it was asked.
+
+The rest of the module arrives phase by phase. **Nothing is registered before it
 has something behind it:** a declared trigger nothing emits and a declared slot nothing fills are
 both surfaces an operator can configure and then wait on, which is worse than an absent one.
 
@@ -181,8 +193,8 @@ directory; a symlink answers no and the module is skipped in complete silence.
 
 Either way, the module appears when the process restarts: the volume is read at require time.
 
-Then, in Admin → Rust, add a server: its name, the sidecar's base URL, and the token the sidecar
-printed on first start (`rust-link-sidecar --print-config`). **The token is write-only** — it is
+Then, in Admin → Rust servers, add a server: its name, the sidecar's base URL, and the token the
+sidecar printed on first start (`rust-link-sidecar --print-config`). **The token is write-only** — it is
 stored encrypted through core's own secret box and never returned to any client; the panel reports
 only whether one is set.