docs: move the notification entries under Unreleased

The cherry-pick that replayed them over the 2.12.0 release boundary put both
sections' bullets in the closed 2.12.0 section, which had already been tagged
and published. The 2.12.0 section is now byte-identical to v2.12.0 again.

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

docs/whatsnew.md

@@ -10,24 +10,28 @@ For deep technical notes, see [architecture.md](architecture.md). For the full g
 
 ## Unreleased
 
----
-
-## 2.12.0 — 2026-08-27
-
 ### Features
 
 - **Notifications now say who wrote what, where — and tapping one takes you there.** A new message used to produce the same line every time, *New: 1 channel*, with the app's own name on top and nothing else: not the sender, not the text, not even which channel it landed on. Tapping it did no more than bring the app forward, wherever it happened to have been left. Everything needed was already arriving with the message and simply was not being used. A channel message now shows the channel as the title and `sender: message` underneath, a direct message shows the sender's name and the message itself, and each conversation keeps its own notification instead of one shared line, so a busy channel cannot bury a DM. When several messages arrive in the same place while you are away they collapse into one notification carrying the newest text, with a count beside the name — *#krakow (4)* — rather than replacing each other silently. Tapping opens the conversation it is about: the channel, or the direct-message panel on that contact. That works whether the app was already running or started from cold, in the Android app and in the browser alike, and it reaches the right place without reloading the interface when the app was merely in the background.
 
-- **An instance you can hand to strangers: demo mode.** mc-webui has never had a login, which is the right trade on a home network and the wrong one the moment you share the address — to show the project off, to collect feedback, or because a store wants a dozen testers who use the app for a fortnight. What happens next is predictable: visitors assume the node is theirs and rename it, and the console is right there for anyone curious enough to type into it. Putting `MC_DEMO=true` in `.env` turns the instance read-only for everybody except you. Everything that reconfigures the radio is refused — the name, the coordinates, the frequency and the rest of the radio settings, reboot, advert and flood advert — along with everything that deletes data, everything that reaches other people's repeaters, the update trigger that rebuilds the containers, the settings that publish packets to an external broker, and the handful of things that hand out secrets such as stored repeater passwords, database backups and the server log. The console stays open for the commands that only read, so it is still worth demonstrating, and refuses the rest with a list of what it will accept. What does keep working is the part that makes a demo worth visiting: reading everything, sending messages in channels and as DMs, and changing the theme and layout, which live in your browser and affect nobody else. The refusal happens on the server, in front of every endpoint and on the console's own connection, so a stale page or a crafted request gets the same answer as a click. In the interface the locked controls are greyed out rather than hidden — the point is to show mc-webui off, and a feature nobody can see impresses nobody — with a yellow **DEMO** badge next to the version, a short explanation at the top of Settings and above the console, and a message rather than a silent shrug when something is clicked. Full guide in [demo-mode.md](demo-mode.md).
-
-- **Two ways to keep full access to your own demo.** Locking the instance is only half of it; you still need to administer the thing. `MC_DEMO_TRUSTED_NETS` takes a list of networks — `192.168.0.0/16`, say — whose visitors are never restricted, so from your own LAN the app behaves exactly as it always has, with nothing to type. `MC_DEMO_UNLOCK_CODE` sets a code you enter once under **Settings → Operator access**; the browser is then remembered for thirty days from any network, which is what you want when the instance is published through a tunnel and every visitor looks like it is coming from the same place. A *Lock again* button sits in the same spot for when you want to see the instance the way a visitor does. The cookie holds a derived token rather than the code itself, so changing the code in `.env` logs every unlocked browser out — which is also how you take access back. One warning worth repeating from the guide: if mc-webui is published through a tunnel or a reverse proxy, every visitor arrives from that one address, and if the tunnel runs on your LAN then listing your LAN as trusted would unlock the instance for the whole internet. mc-webui declines to make that mistake — an address that arrives with a proxy header is not matched against the trusted list unless `MC_TRUST_PROXY` is on — and says so in the log at startup, but the safe habit is to use the unlock code whenever the app is not reached directly.
-
 ### Fixes
 
 - **New messages on the channel you had open no longer arrive in silence, and old unread ones stop announcing themselves as new.** Two separate faults made notifications look unreliable even while the app was awake and connected. The first: a message on whichever channel you last had on screen was quietly excluded from notifications, on the assumption that you were looking at it — which is exactly wrong once the app is in the background, and meant that anyone who left mc-webui on their busiest channel was told about every channel except that one. A channel now counts as open only while somebody is actually looking at it. The second: the first time the app compared its unread counts against the server it treated the entire backlog as having just arrived, so a page that loaded in the background could announce *New: 492 channels* about messages that were days old. That first comparison is now only a measurement, and anything already unread when the app starts is treated as history rather than news.
 
 - **Still unresolved: notifications going quiet after a while on Android.** The changes above fix what a notification says and where it takes you, but not the separate problem of the Android app falling silent some minutes after you switch away from it. That has a different cause — Android freezes apps that have nothing running in the foreground, which stops the connection the notifications depend on — and no setting on the phone can prevent it. Fixing it properly needs a background service in the app itself, which is planned for a later release.
 
+---
+
+## 2.12.0 — 2026-08-27
+
+### Features
+
+- **An instance you can hand to strangers: demo mode.** mc-webui has never had a login, which is the right trade on a home network and the wrong one the moment you share the address — to show the project off, to collect feedback, or because a store wants a dozen testers who use the app for a fortnight. What happens next is predictable: visitors assume the node is theirs and rename it, and the console is right there for anyone curious enough to type into it. Putting `MC_DEMO=true` in `.env` turns the instance read-only for everybody except you. Everything that reconfigures the radio is refused — the name, the coordinates, the frequency and the rest of the radio settings, reboot, advert and flood advert — along with everything that deletes data, everything that reaches other people's repeaters, the update trigger that rebuilds the containers, the settings that publish packets to an external broker, and the handful of things that hand out secrets such as stored repeater passwords, database backups and the server log. The console stays open for the commands that only read, so it is still worth demonstrating, and refuses the rest with a list of what it will accept. What does keep working is the part that makes a demo worth visiting: reading everything, sending messages in channels and as DMs, and changing the theme and layout, which live in your browser and affect nobody else. The refusal happens on the server, in front of every endpoint and on the console's own connection, so a stale page or a crafted request gets the same answer as a click. In the interface the locked controls are greyed out rather than hidden — the point is to show mc-webui off, and a feature nobody can see impresses nobody — with a yellow **DEMO** badge next to the version, a short explanation at the top of Settings and above the console, and a message rather than a silent shrug when something is clicked. Full guide in [demo-mode.md](demo-mode.md).
+
+- **Two ways to keep full access to your own demo.** Locking the instance is only half of it; you still need to administer the thing. `MC_DEMO_TRUSTED_NETS` takes a list of networks — `192.168.0.0/16`, say — whose visitors are never restricted, so from your own LAN the app behaves exactly as it always has, with nothing to type. `MC_DEMO_UNLOCK_CODE` sets a code you enter once under **Settings → Operator access**; the browser is then remembered for thirty days from any network, which is what you want when the instance is published through a tunnel and every visitor looks like it is coming from the same place. A *Lock again* button sits in the same spot for when you want to see the instance the way a visitor does. The cookie holds a derived token rather than the code itself, so changing the code in `.env` logs every unlocked browser out — which is also how you take access back. One warning worth repeating from the guide: if mc-webui is published through a tunnel or a reverse proxy, every visitor arrives from that one address, and if the tunnel runs on your LAN then listing your LAN as trusted would unlock the instance for the whole internet. mc-webui declines to make that mistake — an address that arrives with a proxy header is not matched against the trusted list unless `MC_TRUST_PROXY` is on — and says so in the log at startup, but the safe habit is to use the unlock code whenever the app is not reached directly.
+
+### Fixes
+
 - **Syncing a repeater's clock now uses the server's time, and your own node's clock is kept right by itself.** Pressing *Sync clock* under **My Repeaters → Actions** could set a repeater to a time that was wrong by an hour or more, and the time it reported back rarely matched what the same panel showed a minute later. Two separate things were behind it. The command mc-webui sent asked the repeater to copy the timestamp out of the packet that carried the command — and that timestamp comes from your own node, not from the server, because the firmware deliberately stamps command packets with its own clock. Your node's clock, meanwhile, is only ever set by hand and then left to run free, and on boards without a dedicated timekeeping crystal it drifts badly: the test device here turned out to be sixteen hours behind. So the button was faithfully copying a wrong time onto the repeater. mc-webui now puts the moment inside the command itself, taken from the server's clock and untouched by anything in between, and it checks your node against the server when it connects and once an hour after that, correcting it whenever it has drifted more than half a minute. One limit is worth knowing, because nothing in the app can work around it: the firmware refuses to move any clock backwards, so a node or repeater that has run *fast* cannot be corrected over the air at all and needs a restart before it will accept the right time. When that applies to your own node it is now written to the log instead of being retried in silence every hour.
 
 - **Clocks now say which timezone they are showing.** The same instant was being written three different ways with nothing on screen to tell them apart: the *Clock* row under **My Repeaters → Status** is drawn in your browser's timezone, the console printed the server's, and repeaters answer their own `clock` command in UTC. Reading 17:16 from one and 19:16 from another, minutes apart, is enough to make a perfectly healthy setup look broken. The Status row now names the zone alongside the time (`23.08.2026, 21:21:01 CEST`), and the console prints both readings at once (`2026-08-23 21:15:50 CEST / 19:15:50 UTC`), so a console reading can be held against a repeater's own reply without doing the arithmetic first.