docs(changelog): note two /settings update-flow UX gaps for next release

End-to-end validated the Phase-2 self-update today on a fresh install
(192.168.178.128 → 26.0-alpha → 26.3-alpha): the symlink flip, the
tarball verify, the stage-by-stage progress, and the rollback slots
all work. But two browser-side UX bits are rough:

1. The "Installed" version displayed on /settings doesn't refresh
   right after the update; a hard reload shows the new value.
2. The auto-reload that should fire 5s after stage=done missed on
   the test — the polling connection likely dropped during the
   mid-update API restart.

Neither affects the integrity of the update itself. Landed the notes
in [Unreleased] so the next release cycle picks them up.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -7,6 +7,11 @@ This project uses calendar versioning: `YY.N-stage` (e.g. `26.0-alpha` = 2026, r
 
 ## [Unreleased]
 
+### Known UX gaps (to fix in the next release)
+
+- **Settings page "Installed" field doesn't refresh right after a self-update.** After `/settings` → Update now → success, the browser's `refresh()` against `/status.json` reads a page-load snapshot rather than the new value. A force-reload (Ctrl+F5) shows the correct version. Fix idea: have the update-check endpoint response also drive `upd-current` (we already set `upd-latest` from it).
+- **Auto-reload on update completion is unreliable.** The JS polls `/update-state.json` and calls `location.reload()` 5s after seeing `stage: done`. On the 2026-04-16 VM test the browser never auto-reloaded — user reloaded manually. Probable cause: the API restart mid-apply drops the polling connection between the browser and the page before the done state is observed. Fix idea: fallback `setTimeout(reload, 45_000)` on apply-click regardless of poll outcome.
+
 ## [26.3-alpha] - 2026-04-16
 
 ### Fixed