Leave waits for value 0 out of the count of game waits that returned with event-ordered work held.

vk_backend.c synced_held_count counts the game's fence waits that return while a submission stopped at an event wait
is still held, to decide whether the value should be signalled only after the held remainder (F-2-05). The window
acquire's sync is fenced with value 0 (nvn_api_obj.c nvnWindowAcquireTexture), so a game's wait on it reached the
counter as a wait for 0, which no held submission signals: 6 of the 12 "a game's wait for N returned with K
event-ordered submission(s) still held" lines in the two 0.10.0 fresh sessions were "wait for 0". The counter now
returns at once for value 0, before counting.

Not done here: counting only the waits for values at or after the oldest held submission, which needs its value kept
in vk_exec.c's continuations. Diagnostic only. Not reproduced before the change (it needs a game run).
vk_backend.c compiles with the dev flags and with -Wall -Wextra without new warnings; frame_step_check passes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

runtime/vk_backend.c

@@ -929,8 +929,11 @@ static void vk_be_guest_read(uint64_t addr, uint64_t size) {
 // event wait returns its value with its remainder held for a later replay, so the game may take a wait for that value
 // as the whole submission done and reuse what the held part still reads. How often that happens decides whether the
 // value should be signalled only after the remainder (audit finding F-2-05). The count is unlocked: a diagnostic.
+// A wait for value 0 is left out: the window acquire's sync stands for no submission (nvn_api_obj.c
+// nvnWindowAcquireTexture gives it fence 0), and such waits were half of the lines in two sessions of 2026-11-13.
 static uint64_t synced_n, synced_held;
 static void synced_held_count(uint64_t fence) {
+    if (!fence) return;
     synced_n++;
     int held = vk_exec_held();
     if (!held) return;