status: cancel-all reverts pending changes to last applied config

- lib.common.revert_to_applied(): restore a config file from its
  _last_applied_config snapshot (stamped hash); no baseline -> skip with
  reason, file untouched
- firewall config_apply now stamps the applied baseline like the other
  subsystems; GET /firewall/config and the state collector strip the
  internal _last_applied_* keys
- POST /status/cancel-all + /api/status/cancel-all: revert pending
  subsystems, {cancelled, skipped, errors}, partial-failure safe
- dashboard: "Cancel All Changes" button with confirm modal
  (CancelConfirm, reuses the pending-changes modal rows); the pending
  changes card is hidden entirely when nothing is pending
- tests: revert_to_applied, status_cancel_all, firewall stamping/meta
  stripping, /api/status/cancel-all route, node tests for CancelConfirm;
  firewall _config_apply tests no longer write the real repo config
- docs: api.md, state-model.md, config.md, hoover.md

docs/state-model.md

@@ -17,6 +17,17 @@ return annotation references them.
 - A subsystem whose collection failed holds `null`/`None` in the state
   store — WS snapshots and deltas skip `null` payloads so a failed
   collector never overwrites good client data.
+- Config-backed subsystems record their applied baseline inside the config
+  file itself: `_last_applied_config` (the full merged config at last
+  apply) and `_last_applied_hash` (its SHA-256). A hash subsystem's
+  `status.pending_changes` is true when the current (merged) config hash
+  differs from the recorded hash; `status.pending_diff` lists the field
+  changes since that snapshot. All apply operations (including firewall
+  `config_apply`) re-stamp the baseline. These bookkeeping keys are
+  internal and stripped from every state/API config payload. Canceling
+  pending changes (`POST /api/status/cancel-all`) restores a pending
+  config file from its snapshot; a subsystem with no recorded baseline
+  (never applied) is reported as skipped, not reset.
 
 ## State shape summary