if_seq_no 与 if_primary_term

做的事：真实分别只传if_seq_no、只传if_primary_term这两种"只给一半"的写法，看ES会不会接受

代码真实索引文档拿到_seq_no=0, _primary_term=1 PUT /sp_test/_doc/1?if_seq_no=0 {"n":2} # 真实只传if_seq_no PUT /sp_test/_doc/1?if_primary_term=1 {"n":2} # 真实只传if_primary_term

验证：两种"只给一半"的写法真实都被直接拒绝了，报错精确指出这两个参数必须成对出现

只传if_seq_no=0:
→ 400 "ifSeqNo is set, but primary term is [0]"

只传if_primary_term=1:
→ 400 "ifSeqNo is unassigned, but primary term is [1]"

这组真实报错在请求校验阶段就把规则说清楚了：if_seq_no和if_primary_term真实被设计成必须成对出现，缺一个都真实过不了参数校验这一关。这背后的真实逻辑是：单独一个seq_no真实不足以唯一确定"这是哪一次写入"——本系列上一篇提到过，primary_term真实是主分片故障转移时才会递增的更粗粒度标识，如果只检查seq_no而不检查primary_term，真实有可能在主分片切换的边界场景下，把两个不同"任期"里恰好序号相同的写入操作搞混。

真实验证更关键的一点：故意传正确的seq_no，但配上一个瞎编的primary_term，写入会不会被放行

代码PUT /sp_test/_doc/1?if_seq_no=0&if_primary_term=99 {"n":2} （真实seq_no=0是对的，primary_term=99是真实瞎编的错误值）

验证：哪怕seq_no完全正确，primary_term真实只要对不上，写入依然直接409失败

→ 409 version_conflict_engine_exception:
  "required seqNo [0], primary term [99]. current document has seqNo [0] and primary term [1]"

真实再查文档，确认完全没被改动:
→ {"n": 1}, _seq_no=0, _primary_term=1   ← 真实写入被完整拒绝，文档一个字段都没变

分步演示：if_seq_no与if_primary_term从必须成对出现到各自独立精确校验的完整验证

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