✨ Allow `stepBackward` past a `measure` and `reset q[i]`

🤖 AI text below 🤖

Problem statement

Once a measure has been executed, the debugger refuses to step backward past it. ddsimStepForward in src/backend/dd/DDSimDebug.cpp clears previousInstructionStack after a measurement with the comment // after measurements, we can no longer step back.. The user loses access to the pre-measurement state, both the quantum superposition and the previous value of the target classical bit.

The reset q[i] operation (which performs a measurement internally) follows the same pattern and is also un-stepbackable.

Surfaced during the follow-up work on issue #168 (PR #456) and again during the review of PR #463.

Proposed solution

Applying the inverse of a measurement does not restore the pre-collapse superposition. The operation is genuinely irreversible in a physical sense, and the current code acknowledges this by blocking step back after a measure. Snapshot the state instead: before the measurement writes, save the quantum state together with the previous value of every classical bit it is about to touch. On step back, restore the snapshot. In the DD backend this is cheap because decision diagrams share structure through internal tables, so a snapshot is a pointer rather than a full state-vector copy.

Also drop the previousInstructionStack.clear() calls on the measure path and the reset q[i] path so the step-back path is actually reachable.

Open question

After stepping back past a measurement, the next stepForward can either re-sample the measurement (probabilistic: the operation runs again on the restored superposition and may give a different outcome) or force the previous outcome (deterministic replay: reproduces the original run bit-for-bit, at the cost of storing the outcome and/or the random-number generator state alongside the snapshot).

My preference would be probabilistic: it matches the simulator's natural semantics, requires no extra state beyond the snapshot already needed, and lines up with what a user would see on real hardware. Deterministic replay reads more like a separate feature (a "record-and-replay" mode) than an inherent part of step-back.

Final call is yours; happy to go the other way if you prefer.

Out of scope

• Broader changes to the debugger's history model (call/return stacks, breakpoint state, etc.).
• Persisting classical bit values across code reloads.
• Restoring classical bits after non-measurement operations that write to them (there are currently none in the debugger's front-end).

Start in src/backend/dd/DDSimDebug.cpp, especially ddsimStepForward and the measurement and reset q[i] paths. Trace how previousInstructionStack and the DD state are stored and restored, then inspect existing debugger step-back behavior. Done means stepping backward across both operations restores the quantum state and affected classical bits, with the forward replay behavior resolved.