Fix back-to-cancel behavior of editor

CLAUDE.md

@@ -75,14 +75,19 @@ Prefer separate, human-readable `.html` files over inlined HTML strings in Go. E
 - Do not inline JS in templates or merge unrelated features into one file
 - `ALT+SHIFT` is the modifier for all keyboard shortcuts — do not introduce others
 - Editor toolbar buttons use `data-action` + `data-key`; adding `data-key` auto-registers the shortcut
-- The editor is a *mode* of a page, not a destination. `history-nav.js` turns any
-  same-path `?edit` link (and the editor's CANCEL link back out) into
-  `location.replace`, and SAVE POSTs via fetch and then rewrites the entry with
-  the saved page. Net effect: an edit session never occupies a history entry of
-  its own. Links to a *different* page's editor (new page / new child) still push.
-  The save POST answers `204` + `X-Target` when the request carries
-  `X-Save-Mode: replace`, because the target may hold a `#section` anchor only
-  the server can compute and fetch drops fragments from followed redirects.
+- The editor is a *mode* of a page. Opening it pushes a normal history entry so
+  the browser/Android Back button cancels the edit and returns to the page — this
+  "back to cancel" gesture takes priority. `history-nav.js` only rewrites the way
+  *out*: leaving the editor via the same-page CANCEL link uses `location.replace`
+  so the editor entry is collapsed rather than sandwiched between two page entries
+  (which would let Back walk back into the editor). SAVE does the equivalent — it
+  POSTs via fetch and then `replaceState`s the editor entry with the saved page,
+  so the editor never lingers in history once you leave it (the pre-save page
+  snapshot one step back is the accepted cost). Links to a *different* page's
+  editor (new page / new child) push normally. The save POST answers `204` +
+  `X-Target` when the request carries `X-Save-Mode: replace`, because the target
+  may hold a `#section` anchor only the server can compute and fetch drops
+  fragments from followed redirects.
 - For mutating modals (anything that POSTs and then navigates), call `closeModal()` and then `postReplace(action, body, target)` from `page/actions.js`. Do NOT use `<form>.submit()`. Two reasons:
   1. The modal must be removed from the DOM before navigation, or the browser's bfcache snapshots it open and back-nav restores the modal.
   2. `postReplace` uses `window.location.replace` so the action + result occupy a single history entry. A naive POST → 303 → GET creates two entries, and back-nav lands on a stale pre-mutation snapshot of the same page.