r456 keep the copy staging snapshot alive across opdef retries (the r455 operand-shift root cause)

The fail4 pipeline-order snapshot (captured when a device-dst H2D copy is
held for its operand pins) was freed by svc_opdef_clear on the APPLY path
on every re-decode pass of the held entry. The retried copy therefore
re-captured from the driver's REFILLED ping-pong staging: the a1 H2D of
the r455 streams2_probe D run executed ~3 s after its push carrying a2's
bytes (snapshot first4 flipped 00000000 3f000000.. -> 00000000 3e000000..
across retries; sema-bigcopy dst16_after=000000000000003e0000803e0000c03e
proves the a2 pattern landed in da1's page; the vadd computed a2+b1 and
the readback faithfully delivered it - there is no separate read-side
landing bug for this class).

- svc_opdef_clear: keep the snapshot on the APPLY path (the pass's own
  op execution, which consumes the snapshot on success, follows the
  apply); every genuine consume path (FINISH/FLUSH/DROP/STALE/COUNTED/
  SWEEP/STOP) and the TTL still free it.
- svc_copy_snap_capture: evict same-ring-slot snapshots with a different
  push hash (slot reuse) so the surviving snapshot can never serve a
  fresh push.
- svc_run_ops: an op skipped via ops_done drops any snapshot a later
  re-decode re-captured for it (the leak the r444 APPLY-free used to
  sweep).

0 files changed, 0 insertions, 0 deletions