vgsp-sema: completion gate for the counter publish - never publish GP_PUT while entries are outstanding

r205 regression (my 8c634144 + 5de33b14 + m180): victory_mail fails in
13 s (was green on r202), victory_matmul hangs 242 s. Root cause: the
rank-pollution fix made svc_counter_publish target the channel's OWN
completion word (release_pa ?: counter_pa), but the publish writes the
ring GP_PUT - the client's SUBMISSION position - into that word. While
the pump still has entries to run the pushes are not complete, so the
publish short-circuited every client wait. Witness (r205, mail):
'[129589.831085] pub-adv h=0x5c000019 pa=0x1274beff0 val=108 cur=104'
(after 'walk ... put=108 get=104 last=104'): the waited word jumped to
the submitted 108 ~1 s BEFORE the engine ran ('[129590.802500] output
retirement wait: 1/968 pages changed after 372 ms (settled)'), the
release payloads for the remaining pushes were then forward-only-
skipped, the client's sync returned early and it dumped the stale
buffer -> STATUS FAIL. Pre-fix comparison (r202, green): the same
client's waited word (pa=...ff0) advanced ONLY by sequential release
payloads ('rel-apply ... pay=1..108 -> written'), while the publish
targeted the ascending slot (pa=...ec0) nobody polls - so the correct
completion timing came from the releases alone.

Fix: gate the publish on the pump's own consumed position - write the
GP_PUT only when nothing is outstanding (ch->last_get == put, the same
equality the entry loop consumes to; wrap-safe for the 1024-entry
rings). The releases remain the completion authority; the publish is
reduced to its designed role: the catch-up for entries the pump
consumed without decoding a release. The descending autoreg and the
release_pa ?: counter_pa target stay (they are what stops the busy
rank-16 channel's put from polluting rank 3's waited word - the evtest3
fix, still required: pre-fix r202 style would redirect that write back
onto 0x20400ffc0).

0 files changed, 0 insertions, 0 deletions