Clarify traceout! semantics relative to ptrace across simulator backends

Summary

QuantumInterface declares both ptrace and traceout!, but the ecosystem currently uses traceout! for three materially different operations:

1. an exact, non-mutating partial trace that returns a smaller state;
2. an in-place reduction that retains the original native subsystem storage; and
3. a stochastic pure-trajectory reduction whose ensemble reproduces a partial trace.

The only generic behavior currently supplied by QuantumInterface is:

traceout!(s::StateVector, i) = ptrace(s, i)

Source

Consequently, generic downstream code cannot infer from traceout! whether the input is mutated, whether nsubsystems decreases, or whether the returned state is the exact reduced state or one sampled trajectory.

Current behavior

Relevant implementations:

• QuantumOptics operator delegation and dense ptrace, including ptrace(::Ket, ...).
• Gabs GaussianState is a StateVector and implements ptrace.
• QuantumClifford traceout! versus QuantumClifford ptrace.
• QuantumSavory's MCKet.traceout!.

Concrete downstream problem

QuantumSavory PR #519 exposed the storage difference. QuantumSavory removes a register backreference and renumbers later subsystem indices after traceout!. That is correct for QuantumOptics, Gabs, and its Monte Carlo wrapper because their returned native states are smaller.

With QuantumClifford, however, native tableau columns remain allocated. QuantumSavory's surviving register indices then no longer identify the corresponding native columns. PR #519 therefore needs a private backend adapter that calls QuantumClifford ptrace instead of traceout!.

Questions for the interface contract

1. Should ptrace(state, indices) be the exact, non-mutating operation that always returns a state on the complementary subsystem space?
2. Should traceout! be required to produce the same mathematical and storage result as ptrace, with mutation only as an optimization?
3. Must a successful traceout! decrease nsubsystems, or should retained/padded native storage be a supported contract with an explicit trait?
4. If retained-column erasure is useful for reset and fixed circuit positions, should it have a separate name from partial trace?
5. Should stochastic trajectory discard have a separate interface or an explicit trait, since one result is conditional while only the ensemble equals ptrace?
6. Given that the current StateVector and QuantumOptics Operator methods do not mutate their inputs, should the bang-name contract be documented as "may mutate", or should the functional operation use another name?

Suggested outcome

A documented contract should let backend-neutral code determine at least:

• whether the operation is exact or trajectory-sampled;
• whether the original object can be mutated;
• whether the returned native state has fewer subsystems; and
• when traceout! is guaranteed to be equivalent to ptrace.

The resolution does not need to prescribe one storage strategy, but the distinction needs to be queryable or represented by separate operations.

Start with the StateVector fallback in src/abstract_types.jl, then compare the cited QuantumOptics, Gabs, QuantumClifford, and MCKet implementations of ptrace and traceout!. Determine which semantics the interface can expose for mutation, subsystem count, exactness, and trajectory sampling. Done means the contract is documented or represented by distinct operations or queryable traits, with the backend differences addressed.