vgsp-gr r607: the stream-order watermark must watch EVERY ring, not engine_type!=0 (final form of r590b, on the r606 red-draw capture)

The r606 fresh-boot first mail client drew the classic red VADD
(bad=32735 csum=8139264, c = a + 0) with the peek armed, and the capture
names the blindness exactly:

  362177.927 GR-DEC push=0x20043c394 dropped=9 partial=1 dstpend=0
             copypend=0 ceback=0 defer_exp=0
  362178.001 peek-backlog h=0x5c000059 eng=0 put=95 last=92
  362182.145 peek-backlog h=0x5c000059 eng=0 put=95 last=92
  362182.556 GR LAUNCH submitted (one-shot arg-defer retry)
  362182.882 ce-soft-copy va=d_b executed - 326 ms AFTER the forward
  -> VADD bad=32735 csum=8139264

The driver's H2D relocation copy sat three entries behind on the
COMPUTE-class channel h=0x5c000059 (eng=0) for 4.7 s, held by
'sema-pend: hold h=0x5c000059 idx=90 ... (operand pending)' - the wait
group (0x20480fff0 pay=84) passed every pass, so the only guard blindness
was the engine_type filter: ceback=0 while the copy channel was provably
behind. The r590 watermark now considers every other channel of the
device (the launching channel itself is excluded: its ring legitimately
runs ahead with future entries). Same pass snapshot, same bounded
busy-defer; this guard never refuses - the r586 fail-closed branch is
separate and fires only when argument pages never resolve. r595's
GR-class ops admission has since cut hold resolution to 0.5-4.7 s (the
captured 4.7 s), well inside the 15 s cap, so the deferral ends by
forwarding with the copy executed.

Companion to r605 (newest-registered-first walk within the class): r605
drains consumable published entries before the launch decision in the
same pass; r607 defers the decision while any other ring still holds
unconsumed entries (held chains included).

0 files changed, 0 insertions, 0 deletions