Istio 服务间 mTLS 证书自动轮换后 gRPC 长连接偶发断连，如何做到零中断？

【背景】 我们在 K8s 1.27 + Istio 1.20（ambient/waypoint 未启用，走 sidecar 模式）里给一批内部服务开了 STRICT mTLS，服务间走 gRPC。目标是"证书到期自动轮换、业务无感知"。CA 用的是 Istio 自带 citadel（self-signed root），leaf 证书默认 24h 一次轮换，root 一年一换。

【现象 / 卡点】

1. 普通 HTTP 短连接基本无感，但gRPC 长连接 / 流式调用在轮换窗口内会偶发 UNAVAILABLE: upstream reset 或 TLS error: certificate verification failed，大约每轮换一次就有 1%~3% 的在途连接被打断，业务侧表现为流式推送掉一段、要重连。
2. 我怀疑是 Envoy sidecar 对"同一 upstream 连接复用旧证书 + root 链还没刷新"的竞态：leaf 先换了、验证端手里的 trust bundle 还没生效，导致握手校验失败。
3. 试过把 leaf TTL 从 24h 拉长到 72h，降低轮换频率，断了但断连概率没降——说明问题不在频率而在"轮换瞬间在途连接的处理"。
4. root 证书到期那次更糟：几乎所有服务同时刷 trust bundle，出现了几分钟的验证风暴。

【已尝试】

• 确认 istio-proxy 的 VERIFY_CERTIFICATE_AT_SNI / SDS 配置，SDS 走 K8s Secret 下发；
• 客户端加了 gRPC 重连（指数退避 + jitter），能恢复但有数据空洞，对推送型业务不可接受；
• 把 STRICT 临时降级到 PERMISSIVE 观察，断连消失，证实是 mTLS 握手竞态，但降级不符合零信任要求，只能当止血手段。

【期望得到的答案形态】 希望有人给一套可落地的"mTLS 轮换零中断"方案，具体到：

1. Envoy / Istio 侧如何保证"先换验证链、再换 leaf"或"双证书平滑切换"的正确顺序与配置项（PeerAuthentication、ServiceEntry、SDS 相关）；
2. 对 gRPC 长连接，是否该用连接级热替换而非断连重连，有没有推荐的 client 侧配置（如 keepalive、GRPC_GO_* 或 Envoy connection_pool 参数）；
3. root 证书到期时如何做分批轮换，避免全集群同时刷 trust bundle 的验证风暴；
4. 一套可观测手段：如何用 metrics / 日志快速定位"这次断连到底是 leaf 还是 root 竞态"。 能给出 istio 配置片段或 Envoy flag 清单就更好。