[deferred] Site-profile layer: generalise the CDS backend beyond the 40m

**Component 2 — deferred.** Blocked on Component 1 (the exit gate) landing first.

Component 1 is deliberately built **site-agnostic**: it must not hard-code a single 40m channel name or
the `C1` IFO value. This issue is where the site-specific material goes, kept separate precisely so it can
be reviewed and generalised rather than baked in — the goal being that non-40m hardware needs only a new
profile, not code changes.

Scope — **data in a profile, not code**:

- Channel naming (the `:SUS-_..._EXC` / drive-monitor / readback pattern).
- The site IFO key (`C1` at the 40m) consumed by the transport's environment precondition.
- Counts ↔ newtons calibration, and the DAC / coil limit that feeds the pre-injection peak ceiling.
- OSEM basis matrix (this repo already has [`src/system_ident/osem.py`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/osem.py): EUL2OSEM / OSEM2EUL for
UL/UR/LR/LL/SIDE, reaching only L,T,P,Y — **V and R have no OSEM actuation**, rank 4).
- Front-end sample rate, cross-checked against the probed rate.

Design constraint: everything here must be loadable from a config file and validated, so a second site is
a new YAML plus a `provenance.record()` entry — not a patch.

---
**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.*

Start by reading src/system_ident/osem.py and the linked CDS hardware backend spec, plan, and bring-up handoff. Define the profile data and validation boundaries only after Component 1 and the plan are reviewed. Done means a site can be added through a YAML profile and provenance.record() entry without code changes.

Written by the indexing model from the issue text.