vgsp-gr r611: the stream-order watermark considers only op-carrying channels - sibling launch rings caused mutual deferral

r607 made the CE submission watermark watch every other ring. That caught
the copy channel the r568 class needs, but it also caught sibling GR LAUNCH
channels, whose rings legitimately hold the client own future launches:
streams2s two stream channels (h=0x5c00001f/23) each saw the others
published entry as backlog, deferred for the full 15 s cap, and the r586
fail-closed then refused BOTH kernels (r610c streams2 as the first client of
a fresh boot: every launch REFUSED, STREAMS n=32768 bad=65534).

A channel that carries the client stream-ordered memory work is exactly a
channel that has decoded a transfer op; measured across r606/r609/r610c, ops
appear only on the 0x5c000059 copy family and the CE ranks, and the GR
launch channels decode none. Mark it in the op-append block (ever_ops) and
scope the watermark to those channels: the r606 red-draw copy channel stays
in scope, the sibling launch rings no longer defer.

0 files changed, 0 insertions, 0 deletions