vgsp-sema r610: a replay pass must not re-mark a copy entry as operand-pending - the held-chain livelock

The fail4 r302 block marks a denied device-destination copy op_tr_pending so
the m163/opdef hold retries it. It fires on EVERY decode pass with
allow=false - including a REPLAY pass, which is the pump re-walking an entry
whose ops were already recorded complete for this identity (entry_replay =
same && slot_ops_complete). The re-mark therefore un-completes a slot whose
copy HAS run: the next pass is fresh, re-executes the op, the next pin-batch
rewind re-marks it again - a replay/fresh/replay cycle that re-arms a 3 s
opdef hold every round and stalls the whole copy channel behind it.

Measured: 100% of the op_tr_pending marks in the r604-r609 boots came from
replay passes (27/27 in r609; 71/71 in r606, whose captured held chain
idx=90/92 is this shape; 72/72 in r608). In the r609 boot the d_b H2D entry
(idx=94) was re-marked and re-run every ~0.3 s from 368841 while the vadd
launch waited on it; the launch then hit the r586 fail-closed cap at 15 s
and the engine never wrote (VADD bad=32767 csum=0).

r308's rationale for the replay re-mark (pre-r595 the eng==0 copy channel's
fresh passes never admitted ops, so the re-mark was the only retry hatch) no
longer holds: r595's cap_trust admission runs a plausible copy on its fresh
pass, and a genuinely failed copy keeps its slot incomplete via op_owed / the
svc_run_ops rc!=0 pending rule. The whole denied accounting block (dstpend
note, staging re-snapshot, pending mark, hold) is now skipped on replay; a
fresh (non-replay) denied pass marks exactly as before.

0 files changed, 0 insertions, 0 deletions