Port the Quantum Fourier Transform (QFT) all-to-all implementation to Rust

[simona-rc]

Summary

Migrates synth_qft_full from a pure-Python implementation to Rust. The implementation includes:

• crates/synthesis/src/qft/qft_decompose_full.rs - construct the textbook Quantum Fourier Transform (QFT) circuit.
• qiskit/synthesis/qft/qft_decompose_full.py - thin Python wrapper that delegates circuit construction to Rust. The inverse, when needed, is performed in Python because the Rust API currently does not provide an equivalent CircuitData function.
• All existing tests passed. Additinally, tested correctness by comparing the current implementation against the original version as follows:
  • Unitary equivalence - exact Operator comparison for all parameter combinations up to 12 qubits.
  • Gate-sequence match - instruction-level comparison (gate name, qubit indices, angles rounded to 12 decimal places) up to 100 qubits.
  • Gate-count formula - verifies H, CP, and Swap counts against the closed-form formula for circuits up to 1000 qubits.

Performance

Benchmarking compares the Rust implementation (current branch) against the original Python version (main branch):

Number of qubits	Python (ms)	Rust (ms)	Speedup
5	0.0548	0.0060	9.2x
10	0.1675	0.0098	17.2x
20	0.5802	0.0208	28.0x
50	3.3801	0.1020	33.1x
100	13.6543	0.4142	33.0x
200	53.9664	1.7819	30.3x
500	361.6054	20.0564	18.0x
1000	1405.1210	128.3175	11.0x

Speedup ranges from ~9x at 5 qubits up to ~30x at 200 qubits. The decrease at large sizes reflects that circuit construction overhead becomes dominated by memory allocation for the instruction list rather than Python dispatch cost.

AI/LLM disclosure

• I didn't use LLM tooling, or only used it privately.
• I used the following tool to help write this PR description: IBM Bob 2.0.3; I reviewed and checked the tool's suggestions. I also used it to create the local correctness tests.
• I used the following tool to generate or modify code:

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the following people are relevant to this code:

• @Qiskit/terra-core

[CLAassistant]

All committers have signed the CLA.

[Cryoris]

Thanks for having a stab at this! I left some comments below.

[Cryoris]

I think this structure can be optimized, we can avoid iterating over the instruction twice and having different code paths for barrier/no barrier. This should also improve the performance a bit. There's two options that would make sense

1. Write a single loop that calls .push_standard_gate or .push_packed_operation for barriers. This is the simpler one.
2. Build a single large iterator over PackedOperations and construct the final circuit using CircuitData::from_packed_operations -- see e.g. code in the pauli_evolution.rs module doing that.

I would suggest going with 1 for starters.

[simona-rc]

Thank you for the review!
I updated the code using option 1 in
a50c6da

[ShellyGarion]

thanks, I agree that the code looks better now when considering both "with barriers" and "no barrier" options :)

[Cryoris]

LGTM thanks for your contribution @simona-rc !

[Cryoris]

Before merging -- did you want to re-run the benchmarks after the current restructuring?

[simona-rc]

I already did a re-run of the benchmarks and upddated this PR description with the results.