chore: release 2.18.0

Also restores the "## 2.17.0" heading over its entries. That release was
titled on main only, so on dev its content was still sitting under
Unreleased and would have been republished as part of 2.18.0.

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

VERSION

@@ -1 +1 @@
-2.18.0-dev
+2.18.0

docs/whatsnew.md

@@ -10,6 +10,10 @@ For deep technical notes, see [architecture.md](architecture.md). For the full g
 
 ## Unreleased
 
+---
+
+## 2.18.0 — 2026-09-09
+
 ### Features
 
 - **One-click updates now work without cloning the repository.** mc-webui can be installed two ways: by pulling the ready-made Docker image, or by cloning this repository and building it. The ↻ button next to the version in the menu has always told both kinds whether a newer version exists — but **Update now** only ever appeared for a repository installation, because the small service behind it was installed from the `scripts/` folder, which an image installation does not have. That folder is no longer needed: one command installs the service and downloads what it needs, and the whole thing can be removed the same way.
@@ -29,6 +33,10 @@ For deep technical notes, see [architecture.md](architecture.md). For the full g
 
 - **A failed request no longer shows a programmer's error message.** When something in front of the app answered instead of the app — the login page of a reverse proxy or a service like Cloudflare Access after the session had expired, or a gateway error page — the interface tried to read that web page as data and showed what the attempt threw: `SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSON`. It now says what actually happened, and what to do about it: that a login page answered and the page needs reloading and signing in again, or that something in front of the app answered, with the HTTP status quoted for anyone diagnosing it. Requests are read the same way everywhere now, so a genuine error from the app itself keeps its own message — a repeater that did not answer in time still says exactly that.
 
+---
+
+## 2.17.0 — 2026-09-07
+
 ### Features
 
 - **Repeater regions can now be managed from the interface, not just the CLI.** A repeater decides which *flood-scoped* packets it passes on from its own list of regions — a name like `pl` that a sender stamps on a packet, which only repeaters allowing that region will forward. Setting that up meant typing `region` commands into the console and reading back an indented text tree. **My Repeaters → Settings → Regions** now shows that tree as a list: each region with its **Flood allowed** / **Flood denied** state, nested regions indented under their parent, and the **home** region marked. A ⋮ menu on each row allows or denies flood, sets the home region, **moves the region somewhere else in the hierarchy** (previously only possible by deleting it and adding it again), or deletes it, and **Add region** takes a name plus an **Inside** picker, so a region can be nested inside an existing one or left at the top level. The wildcard row at the top — *Packets without a region scope* — is the rule for ordinary unstamped packets, and can be switched like any other. Below the list, **Default scope** sets the region this repeater stamps on packets it sends itself.