### wai-quantum: device targets and calibrated noise

The engine knows real devices: their qubits, pairs, native gates, durations and errors. A program is compiled, laid out and simulated as it would run on one.

- **The model** (`engine::targets`): each qubit's T1, T2, frequency, readout assignment errors and measurement time; each native gate where it runs, with its error and duration; the coupling map; and the calibration snapshot's id and time. It is one strictly read document, `wai.quantum.target/1`, with a JSON Schema, and the BLAKE3 hash of its RFC 8785 text names the snapshot in a receipt.
- **Importers:** the per-qubit and per-gate calibration properties a superconducting-device service publishes (alone or beside its configuration, the form published snapshot devices ship in), an instruction-properties target, the device-capabilities document a cloud service returns, and the open provider protocol's `describe`. Four built-in targets, all synthetic, one in each shape: a 5-qubit line, an 8-qubit ring, a 27-qubit heavy-hexagon lattice and 5 qubits all coupled.
- **Noise from a target**, per qubit and per pair. Each gate's reported error becomes the depolarising channel that, with its relaxation, has exactly that average infidelity. T1, T2 and the durations give amplitude damping and dephasing, idling included, and readout comes from the assignment matrix. The density matrix and the branching trajectories take it as a schedule of channels (`quantum_noisy::Schedule`). The global noise model keeps its bits.
- **Noise-aware layout and routing:** many layouts and their most reliable routes are compared, and the highest expected success is kept. The compiler's own choice (the fewest swaps) wins unless beaten, and the program is checked against the circuit. `native::compile_at` and weighted routes are new; `native::compile` is unchanged. A provider whose `describe` states its calibration gets its programs placed the same way, in the device's own gates and checked before they are sent, and the receipt says how. The provider protocol now states the `durations` field's form.
- **Job JSON:** `target` is a document or a built-in target's name. The plan states the layout, its expected success beside the fewest swaps', and the noise derived. The result carries the same with the target's hash, inside the receipt, and the distance of its distribution from the circuit's ideal one.
- **Surfaces:**
  - the command line: `wai-quantum targets import|list|show|remove|schema` (import also from a provider's describe) and `run --target`/`plan --target`;
  - MCP on both servers: `list_targets`, `show_target`, `run_on_target`, and `target` in the run tools' schemas, with the agent docs regenerated;
  - the service: `GET /v1/targets`, `target` in the OpenAPI document, and a worked example (it reads the document given and fetches nothing);
  - wasm: `engine_targets`, `engine_target` and `engine_target_place`;
  - the desktop app: the same three, the person's kept targets included;
  - the Studio: a **Device** section with the coupling map coloured by each pair's and each qubit's error, the chosen layout drawn on it, a snapshot imported, and the result's **Device** block.
- **Checked against ground truth:**
  - a target with no errors gives the ideal distribution to 1e-12 in each of the three gate sets;
  - T1 decay, T2 coherence and the assignment matrix give their closed forms;
  - each gate's channels have exactly its reported average infidelity, by its Choi state;
  - the layout equals an exhaustive search on a line;
  - a run on a target gives the same bytes natively and under wasmtime (a CI check).
- **Not done:** a cross-vendor C device interface is a library with no document form to import; a host that loads one answers the provider protocol's `describe`, which is read. Programs with angles that are not dyadic are refused on a target, since the compile is exact. Crosstalk, leakage, coherent errors and drift are not modelled.

