Fix process-based non-determinism in SparsePauliOp.to_matrix

The simplification step of the summed Pauli terms in
`SparsePauliOp.to_matrix` had introduced a non-determinism via hash-map
iteration.  In practice, the base hash seed was set per initialisation
of the extension module, then stayed the same.  This is hard to detect
from within tests, but caused unexpected numerical behaviour on
different invocations of the same script.

Author: jakelishman

crates/accelerate/src/sparse_pauli_op.rs

@@ -20,6 +20,7 @@ use numpy::prelude::*;
 use numpy::{PyArray1, PyArray2, PyReadonlyArray1, PyReadonlyArray2, PyUntypedArrayMethods};
 
 use hashbrown::HashMap;
+use indexmap::IndexMap;
 use ndarray::{s, ArrayView1, ArrayView2, Axis};
 use num_complex::Complex64;
 use num_traits::Zero;
@@ -298,7 +299,7 @@ impl MatrixCompressedPaulis {
     /// explicitly stored operations, if there are duplicates.  After the summation, any terms that
     /// have become zero are dropped.
     pub fn combine(&mut self) {
-        let mut hash_table = HashMap::<(u64, u64), Complex64>::with_capacity(self.coeffs.len());
+        let mut hash_table = IndexMap::<(u64, u64), Complex64>::with_capacity(self.coeffs.len());
         for (key, coeff) in self
             .x_like
             .drain(..)

releasenotes/notes/spo-to-matrix-determinism-554389d6fc98627c.yaml

@@ -0,0 +1,6 @@
+---
+fixes:
+  - |
+    Fixed a per-process based non-determinism in `SparsePauliOp.to_matrix`.  The exact order of the
+    floating-point operations in the summation would previously vary per process, but will now be
+    identical between different invocations of the same script.  See `#13413 <https://github.com/Qiskit/qiskit/issues/13413>`__.