sema-svc: never re-process a GPFIFO slot already consumed in the put epoch

A pin-batch rewind replays recently consumed entries. An old entry whose
rescue cannot validate any candidate then sits in the CE grace path - and
because the client's put has advanced since, the replayed entry no longer
matches any "new" expectation: it waits the full 8 s grace, blocking every
later entry behind it on that channel. Observed live: the first push of
rank 0 re-processed and skipped twice, 38 s apart, while eight later pushes
queued behind it.

The pump now marks each consumed slot in a per-channel bitmap valid for the
current put epoch (cleared when put wraps, so a recycled slot in the next
epoch is processed normally) and consumes a replayed slot immediately.
Rewinds still refresh readable entries; they simply no longer resurrect
entries that were already handled.

Evidence: real-release watcher cycle, replay-after-put-advance no longer
produces 'skipping stale entry ... after 8000 ms grace' for old slots.

0 files changed, 0 insertions, 0 deletions