Stage C: TwinTransport — route CDSBackend at a compiled rtsfreerun model

**Stage C (spec §4.1).**

The second `CDSTransport` implementation: route `start` / `stop` / `fetch` at an rtsfreerun `mdl` with a
**synthetic GPS clock**, so the *same* `CDSBackend` code path runs against a compiled digital-twin model.

This is what makes the campaign's exit gate possible without hardware, and it is how the AWG-shaped
lifecycle (schedule at a future GPS time, settle, fetch, ramp down) gets exercised end to end.

Reuse rather than reimplement: [`src/system_ident/backends/rtsfreerun_adapter.py:96`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/backends/rtsfreerun_adapter.py#L96) already knows how
to drive `mdl.run(cycles=, excitations=, excitation_data=)` and `mdl.fetch_later(t0, t1, names)`, and
[`src/system_ident/backends/rtsfreerun_oracle.py`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/backends/rtsfreerun_oracle.py) supplies scenario init plus the analytic truth for
scoring.

Note the transport must present the **same** interface contract as `AWGNDSTransport`, including returning
real readback samples for the drive channel — the whole point is that `CDSBackend` cannot tell them
apart. In particular do **not** let it synthesise X (see the `read()` invariants issue);
[`src/system_ident/backends/rtsfreerun_adapter.py:228`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/backends/rtsfreerun_adapter.py#L228) does that legitimately for its own backend
because it owns the sample clock, but the CDS path must not.

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

Read the Stage C section of the linked spec and plan, then inspect src/system_ident/backends/rtsfreerun_adapter.py at lines 96 and 228 and rtsfreerun_oracle.py. Trace the AWGNDSTransport contract and the CDSBackend lifecycle. Done means a CDSTransport routes start, stop, and fetch through the compiled model with a synthetic GPS clock, returns real drive-channel readback samples, and remains interchangeable with AWGNDSTransport.

Written by the indexing model from the issue text.