[VesterlundCoder]

Summary

Adds westquant.wqbench, a stricter, resumable compilation-data foundation that sits alongside the legacy generate_training_data API (applied from WQBench_Dataengine_v0_1.patch, rebased cleanly on current main).

• Explicit synthetic Qiskit Targets (line/ring/all-to-all) with hashed backend IDs
• Exact instruction-document content IDs, and a root_id lineage key with a deterministic 80/10/10 split
• Conservative verification: layout-corrected operator equivalence for unitary circuits up to 8 qubits; everything else is UNKNOWN, never an unverified EXACT
• Structured failures with no fabricated zero metrics, SQLite resume, and normalized JSONL export
• Docs: docs/wqbench/README.md, PLAN_v0_1.md and AUDIT.md (audit of the legacy generator)

No package version change. The module is not yet part of a PyPI release.

Reproduction against the control package (WQBench_Dataengine_Kontroll_v0_1)

• circuits.jsonl and backends.jsonl are byte-identical to the control
• 192/192 success, EXACT, target-valid. Resume run: 0 created, 192 cache hits
• 35/192 compiled_qasm3 differ from the control (all random family, optimization level 1–3). 18 differ structurally and 17 only in angles. 15 rows differ in size/op counts and 7 in depth and the proxy metrics. Two-qubit counts are identical in all 192.
  • Same Qiskit 2.6.1 and engine hash. Two fresh local runs are identical apart from timing, so this is cross-machine numerical variation (the control used a different machine; this run used macOS arm64, NumPy 2.5.4).
  • Follow-up suggestion: run_id hashes Qiskit version, engine hash and git commit, but not platform/NumPy/Python. Two machines on the same commit can therefore produce the same run_id with different compiled circuits. Consider adding those to environment.

Test plan

• Full suite: 32 passed locally (Python 3.12, Qiskit 2.6.1)
• python -m westquant.wqbench --dry-run, full run and resume run reproduce the expected counts
• Tests workflow green on this PR

Generated with Devin