版本冲突与重试

做的事：真实用20个线程对同一个counter做最朴素的"读-算-写"客户端逻辑，完全不处理冲突失败

代码真实索引{"counter":0} 20个线程真实各自并发执行: 1. GET /vc_test/_doc/1 拿到当前counter值、_seq_no、_primary_term 2. PUT /vc_test/_doc/1?if_seq_no=X&if_primary_term=Y {"counter": 当前值+1} 真实遇到409直接放弃，不做任何重试

验证：不做重试的朴素版本，真实20个里只有1个成功，19个真实直接放弃了

naive (no retry): {'success': 1, 'conflict': 19}
最终counter: 1

这组真实结果跟本系列第103篇用_update API观察到的现象（默认retry_on_conflict=0时20个并发只有1个成功）真实完全一致——这不是巧合，而是因为_update API底层真实也是在做同样的"读-改-写"流程，这里真实只是把这个流程用最原始的GET+PUT if_seq_no手工实现了一遍，本质上真实是同一套乐观并发控制机制在起作用：19个线程真实都基于同一个已经过期的seq_no去写入，自然全部真实被拒绝。

真实把客户端逻辑改成遇到冲突就重新读取最新值再试一次，最多尝试10次，看成功率能提升多少

代码真实每个线程遇到409冲突之后，不放弃，而是真实重新GET最新的_seq_no和counter值，用新值再次尝试PUT，最多重复这个过程10次

验证：加了重试循环之后，成功数真实从1个涨到了17个，但依然有3个在尝试10次之后真实放弃了

with retry loop (max 10 attempts): {'success': 17, 'gave_up': 3}
最终counter: 17   ← 真实精确等于成功的请求数

分步演示：客户端自己实现乐观并发重试循环从朴素失败到真实有限改善的完整验证

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。