Document the post-1.7.12 M365+GWS scan report and update checks

TODO.md: open entry for "M365 not scanning M365+GWS accounts after the
1.7.12 update" — symptom, what was verified, likely half-applied update,
server checks to run after an update, what to collect if it recurs,
rollback option, and two possible hardening steps.

routes/CLAUDE.md: note that half-applied updates look like code bugs and
to verify server state before debugging a post-update regression.

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

routes/CLAUDE.md

@@ -99,6 +99,7 @@ Optional AI-powered NER replacing spaCy. Activated via `config.json` keys `claud
 - **`apply_update()` never restarts itself** — callers decide. Tests patch `_schedule_restart`; the auto-update thread calls `_restart_self()` directly.
 - **Auto-update thread** — `start_auto_update_thread()` called from `gdpr_scanner.py` `__main__`. Hourly tick, applies at most once per 24 h when `config.json["auto_update"]` is true; skips (and retries next tick) while a scan runs.
 - **`update_gdpr.sh`** — standalone CLI/cron equivalent of the same logic; keep stash/ff-only/requirements behaviour in sync.
+- **Half-applied updates look like code bugs** — `update_gdpr.sh` restarts only if a `gdprscanner` systemd unit exists (else the old Python keeps running under the new static JS), open browser tabs keep old JS modules until reloaded, and both paths auto-stash local edits. Before debugging a post-update regression, verify the server state (HEAD, `VERSION`, clean `git status`, `git stash list`, service start time after the update) — see the "M365 not scanning M365+GWS accounts after the 1.7.12 update" entry in `TODO.md`.
 
 ## Viewer mode — routes/viewer.py