✨ Support directional compiler-target connectivity and operation availability

[simon1hofmann]

🤖 AI text below 🤖

Problem

CompilerTarget::Coupling accepts a pair of site IDs, but target construction currently sorts each pair and builds adjacency in both directions. Target operations are documented as globally available; ordered SiteTuples carry calibration data only. A target therefore cannot express that cx or ecr is native on (u, v) but not on (v, u).

Current implementation:

• CompilerTarget topology and operation model
• Coupling canonicalization and symmetric adjacency
• Mapping's explicit symmetric-coupling assumption

Goal

Represent directional connectivity and ordered operation availability without losing the convenient symmetric and all-to-all target forms. Routing may use the underlying connected graph, but native synthesis and target conformance must respect the legal operand order of directional operations.

Adapters that receive ordered topology or operation data must preserve it rather than silently symmetrizing it.

Minimal reproducer

Create a two-site target where cx is available only on (0, 1). Compiling cx on (1, 0) must either synthesize an equivalent circuit using legal target operations or fail with a precise diagnostic. It must not accept the reversed gate as native.

Acceptance criteria

• The target API distinguishes (u, v) from (v, u) for directional connectivity and operation availability.
• Mapping, native synthesis, and conformance consistently use that direction information.
• Unsupported directions are legally rewritten or rejected; no reversed native operation survives verification.
• Symmetric and all-to-all targets retain straightforward construction and existing behavior.
• C++ and Python tests cover asymmetric cx/ecr, symmetric topology, and an unreachable direction.

Related work: #1709 introduced coupling-map injection. #2119 fixes sparse target-site indexing and is intentionally separate from directionality.