mTLS 证书轮换时 gRPC 长连接被 RST，你们是怎么做到零闪断的？

背景：我们是一个内部 gRPC 微服务集群（约 200 个节点），去年年底上了 mTLS（Istio + 自签 CA，cert-manager 管理），初衷是消除内网明文传输。

现象：每次 CA 侧做证书轮换（周期 24h，cert-manager 触发），部分长连接——尤其是超过 30 分钟的 gRPC stream——会被对端 RST，客户端表现为 UNAVAILABLE: upstream reset before call complete。短连接基本无感，但长连接的业务方投诉明显，每次断连丢 200ms–2s 的 in-flight 数据。

已排查：

1. 对齐 istio-proxy 日志，确认 rotation 时间点与断连时间吻合；
2. 试过把 PILOT_ENABLE_CA_JWKS 关掉、改用纯 SDS 推送，断连仍复现；
3. 客户端加了 exponential backoff 重连，能恢复但业务方不买单（丢帧 + 重放窗口）；
4. 把证书有效期从 24h 拉到 7 天，频率降了但问题没消失，说明根因不是"频率"而是"轮换动作本身"。

期望得到的答案形态：

• 你们在类似规模（100+ 节点、gRPC 长连接为主）下是怎么做 mTLS 轮换的？有没有实际跑通的配置片段（Istio / Envoy / cert-manager）？
• 是不是有某个组件（Envoy SDS、istio-agent、cert-manager）在 rotation 时强制 reload 了 connection pool，从而把已建立的 TLS session 也一起断了？
• 如果必须接受短断，有没有比 backoff 重连更优雅的补偿机制（比如服务端 stream resume、客户端幂等重放、或者 gRPC 层面的 grpc.max_connection_age 调优）？
• 如果你们完全没遇到这个问题，能否分享一下你们的 CA 轮换策略、证书有效期设置、以及 Envoy 的 drain_timeout 配置？