Pipeline + NoCache 情况下，可能出现 Can't truncate logs before _applied_id=22, last_log_kept=0

场景:
1. leader 给某个 peer 安装快照 [last_included_index=22]，完成后 _next_index = 23
2. 然后leader 先后发送两个 append entries rpc ， 分别复制log [23, 28] 和 [29,32]

如果网络原因导致第二个 append entries rpc 先到达。在 NoCache 情况下，会失败。 replicator 把 _next_index 重置并取消掉第一个 rpc。 下面的这个检查又进入到了 truncate log 的分枝。_next_index--，也就是设置为 22。但实际上peer上仅仅是缺少了日志，应该是第一个分支。
https://github.com/baidu/braft/blob/59c40e5d6b487121af5a1826a654138f489d7155/src/braft/replicator.cpp#L442-L463

后续 append entries 的时候， prev_index = 21 ， peer 上是没有的，仍然会失败。然后不停地减小 _next_index 重试，直到变成0触发了 peer 上的 truncate suffix。

Start in src/braft/replicator.cpp at lines 442-463 and trace how out-of-order AppendEntries responses affect _next_index when NoCache is enabled. Reproduce the snapshot-followed-by-two-RPC scenario described in the issue, then verify that a missing-log condition retries the appropriate branch without causing an invalid log truncation or repeated decrement to zero.

Written by the indexing model from the issue text.