docs: correct the multi-tab claim in the whatsnew entry

Testing after the batching fix showed three tabs still push /api/status from
~600ms to a ~13s median, from a different cause (every endpoint degrades
together under load, so a shared lock rather than a request storm). The entry
claimed multiple windows were no longer a problem; scope it to the load
reduction that was actually measured.

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

docs/whatsnew.md

@@ -14,7 +14,7 @@ For deep technical notes, see [architecture.md](architecture.md). For the full g
 
 - **Messages no longer go missing after the app has been in the background.** Coming back to a minimised app — or to a phone that had been asleep — could show a chat that quietly stopped at whatever message arrived last before the screen went off, with everything since then missing until the app was force-stopped and reopened. New messages reach an open page over a live connection, and Android tears that connection down while the app sits in the background; nothing then went back to ask the server what had been missed. Now every way back from a gap re-reads the list: the connection coming back, the app returning to the foreground, and a heartbeat that notices when the page has been frozen. The same applies to direct messages, and to a browser tab that lost its network for a while.
 - **A Refresh item in the menu.** The browser's pull-to-refresh has no equivalent in the Android app, so there is now a **Refresh** entry at the top of the menu that reloads the messages from the server on demand — in the app, and everywhere else too.
-- **The app no longer grinds to a halt with more than one window open.** Keeping mc-webui open in two places at once — a second browser tab, or a phone and a desktop together — could leave the message list stuck on "Loading messages…" and the status on "Connecting…", looking for all the world like the mesh device had dropped off, when it was connected the whole time. Each open window was asking the server about every message on screen separately, hundreds of individual requests at a time, repeated every few seconds as new radio traffic came in; together they left the server no room to answer anything else. Those requests are now bundled into a single one, so a window that used to need hundreds needs one, and several windows at once are no longer a problem.
+- **Far less load on the server while you have messages on screen.** Whenever new radio traffic came in, the page asked the server about every message on screen separately — hundreds of individual requests at a time, repeated every few seconds, and the same messages over and over. On a busy channel that was thousands of requests a minute from a single tab, which left the server little room to answer anything else; the worst of it looked like the mesh device had dropped off, with the message list stuck on "Loading messages…" and the status on "Connecting…", while the device was connected the whole time. Those requests are now bundled into one. A page that needed hundreds of requests per update now needs a single one. Keeping mc-webui open in several windows at once is still not recommended — that can still slow things down for a different reason — but the app is considerably lighter on the server than it was.
 
 ---