ci: temporary fix for windows-latest changed

A follower whose last_applied is at or ahead of an incoming snapshot's
index rejects the install_snapshot_rpc with an append_entries_reply
rather than an install_snapshot_result. The snapshot sender treated this
as fatal (exit(unexpected_install_snapshot_result)), so the reply never
reached the leader and next_index was never corrected — the leader
re-sent the same snapshot indefinitely, until the next election.

The sender now forwards that reply to the leader and exits normally. The
leader's existing success = false handler advances next_index to the
position the follower indicated, breaking the loop.

Adds ra_SUITE test snapshot_installation_target_already_has_snapshot.

Forward follower's append_entries_reply when it already has the snapshot

This appears to be a regression, the init phase should only be
used when there are live indexes to send.

Fix (src/ra_log.erl): set_last_index/2 now clamps pending to the new last index (pending = ra_seq:limit(Idx, Pend0)) in both success branches, matching the same defensive pattern already used in append/2, write/2, write_sparse/3, and commit_tx/1.

Bug it fixes: without the clamp, resetting the log backward (e.g. on a term-mismatch rollback) left stale higher indexes in pending. Since the "old" mem table is kept as the prev link of the freshly-swapped-in one, those stale entries are still physically readable — so if the WAL later sent a {resend_write, Idx} request into that gap, ra_log:resend_from/2 would happily resend the already-discarded, truncated log entries back into the WAL, resurrecting data the reset was meant to get rid of.

Fix stale `last_written`/`pending` state after log truncation, and a snapshot-send regression

Fix `force_shrink_members_to_current_member/1` typespec