bug: Importing deltakit makes stim's `flow_generators` return wrong signs in the same process (0.9.0)

[YaegakiY]

Contributor License Agreement

• A Contributor Licence Agreement signature is required for any first PR contribution. Further information can be found in our contributing guidelines.

Bug Description

After deltakit is imported, real stim's Circuit.flow_generators() returns incorrect flows in the same Python process: signs are dropped or inverted, and on larger circuits generators can reference out-of-range measurement indices. has_flow appears unaffected. This is the opposite direction of #310: there, importing stim first makes deltakit's circuit generation raise; here, importing deltakit first makes stim's flow extraction silently wrong. With deltakit-stim 0.2.1 installed there is no import order in which both libraries behave correctly in one process.

Minimal Reproducible Example

deltakit 0.9.0 from PyPI, stim 1.16.0, Python 3.13:

import deltakit.explorer.codes  # comment this line out and the output is correct
import stim

for f in stim.Circuit("R 0\nX 0\nM 0").flow_generators():
    print(f)

Actual behaviour

1 -> rec[0] and 1 -> Z. The circuit prepares |0>, flips it to |1>, and measures, so the outcome is deterministically 1 and the final state is stabilized by -Z; both printed generators have the wrong sign. On larger circuits (a rotated-planar memory compiled to a SQRT_XX gate set) flow_generators() additionally returned a flow referencing rec[33] in a circuit with 33 measurements (valid indices 0..32). stim.__file__ still points at the real stim installation.

Expected behaviour

1 -> -rec[0] and 1 -> -Z, as printed when deltakit is not imported, regardless of import order.

Additional context

Reproduced 3/3 in fresh interpreters; the only difference between the correct and incorrect runs is the deltakit import. Circuit.has_flow gives correct answers in both cases, so the corruption seems specific to the flow-generator extraction path. The 0.8.x subpackage stack (before the deltakit-stim migration, #248/#263/#277) does not show the behaviour. This looks like the same native type-registration interaction as #310 with the roles reversed: whichever of stim / deltakit_stim loads first owns the duplicate type registrations, and the other library's native paths then misbehave — a crash in one direction (#310), silently wrong results in this one. Environment: macOS arm64, Python 3.13.5. More details available on request.

[rolandriver]

Thank you @YaegakiY for raising this bug. This is currently under internal review and prioritisation. We will come back to you shortly.