fix(raft): queue each committed index once per Ready window

[EnRaiha]

Why

The P2 review left one unexplained shape: a Raft batch carrying the same committed index twice. The applier's delivery guard (each committed index handed off at most once, watermark claimed in one critical section) is the boundary — but the producer-side cause was unknown, and an append-shaped write gains a row if that guard ever slips.

Root cause found: collect_committed_entries resumed from last_applied alone. It runs on every commit-index advance — a follower's AppendEntries, a single voter's propose — while the loop drains Ready and advances last_applied later. Two advances inside one window queued the same committed range twice, putting one index twice into a single batch.

Part of #165 (P2 — cluster consensus safety).

What

• collect_committed_entries resumes past the furthest index already queued into Ready (max(last_applied, queued_through)), so a second advance in the window queues only what is new. No new state, O(1).
• apply_group_commits records the first committed index that is not greater than its predecessor (first_non_increasing_committed_index, zero-allocation windows(2)) with a warn — a producer-side regression is observable, and the applier guard stays the boundary.

Validation

• Red proof: the new raft test fails on the base producer (repeated indices in one batch) and passes with the fix.
• cargo test -p nodedb-raft --lib node:: — 86 passed.
• cargo test -p nodedb-cluster --lib apply_committed — 1 passed (detector).
• cargo check -p nodedb-cluster --all-targets — clean; repository preflight passes.

Notes

• A cross-tick re-queue while the async data-plane apply lags remains possible by design (a fresh Ready starts empty). That is a repeated delivery across batches, covered by the applier's watermark guard, not a duplicate inside one batch.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[farhan-syah]

Root cause verified independently: collect_committed_entries is the only producer of ready.committed_entries, and the loop calls advance_applied only after apply_group_commits, so two commit advances between drains re-queue the range. Fix at the producer, no new state. Correct layer.

Claims verified: red proof reproduces on the base producer ([2, 2, 3]), nodedb-raft node:: 86 pass, nodedb-cluster apply_committed 1 pass, clippy --all-targets -D warnings clean on both crates, fmt clean.

Two inline notes, neither blocks. After the change, amend the commit or squash: one commit on this branch.