[deferred] Guardian / lock-state abort, and full filter-module snapshot/restore

**Component 2 — deferred.** Blocked on Component 1 and on operator sign-off.

### Guardian / lock-state abort

Add a lock-state / Guardian hook on top of the existing `Watchdog`
([`src/system_ident/safety.py:59`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/safety.py#L59)), so a lock loss aborts the campaign through the same idempotent
handoff rather than continuing to inject into a changed plant. Today the watchdog keys only on physical
limits — actuator saturation and per-DoF output RMS — by design
([`docs/tutorial/safety-and-ops.qmd`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/docs/tutorial/safety-and-ops.qmd)), which is right for what it covers but says nothing about the
interferometer's state.

### Full snapshot / restore

Component 1 implements `snapshot_state` / `restore_state` **honestly but minimally**: live-excitation state
only, with the docstring stating that filter-module switch/gain/offset state is not captured.

Completing it means capturing and restoring the filter-module state — and that is a real escalation:

- It needs `ezca` / `pyepics`, absent from [`pyproject.toml:21`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/pyproject.toml#L21).
- It means **writing** to the front end, so it needs explicit operator sign-off on exactly what may be
written.
- Open question from [`notes/strategic-roadmap-2026-07-draft.md`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/notes/strategic-roadmap-2026-07-draft.md) §Phase-C: must the snapshot capture
filter-module *history* (i.e. is `fm_clear_history` required), not just switch positions and gains?

On hardware `restore_state` **is** the "hand control back to the existing damping loops" step
([`src/system_ident/safety.py:9`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/safety.py#L9)), so getting it wrong is a safety issue, not a convenience one.

---
**Campaign:** CDS hardware backend · branch [`feat/cds-hardware-backend`](https://github.com/CaltechExperimentalGravity/system_ident/tree/feat/cds-hardware-backend)
· [spec](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/docs/superpowers/specs/2026-08-03-cds-hardware-backend-design.md) · [plan](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/docs/superpowers/plans/2026-08-03-cds-hardware-backend.md) · [handoff](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/notes/cds-hardware-bringup-2026-08.md)
*Code is deferred until the plan and issues have been reviewed.*

Review src/system_ident/safety.py, especially Watchdog and snapshot_state/restore_state, then read docs/tutorial/safety-and-ops.qmd and the Phase-C section of notes/strategic-roadmap-2026-07-draft.md. Check pyproject.toml for the missing hardware dependencies and resolve the open question about filter history. This is ready only after Component 1, plan review, and explicit operator sign-off define the permitted writes and restore behavior.

Written by the indexing model from the issue text.