Kafka 幽灵会话导致周期性 rebalance，心跳超时后仍被反复踢出组如何根治

【背景】 我们用 Kafka 3.4（5 节点 KRaft，topic order-event 48 分区）承载订单事件分发，消费组 12 实例（K8s Deployment，3 副本 × 4 AZ）。日均约 5000 万条，峰值 8000 msg/s。broker 端开启 group.min.rebalance.delay.ms=3000，消费端 session.timeout.ms=45000、heartbeat.interval.ms=15000、max.poll.interval.ms=300000、partition.assignment.strategy=CooperativeStickyAssignor。

【现象】 凌晨 02:00–04:00 出现周期性 rebalance：每 90–120 秒一次，且总是同一实例先收到 onPartitionsRevoked，随后全组重入。broker 日志反复出现 Member xxx has failed, removing it from group，但对应 Pod 的 CPU/内存/网络完全正常，JVM GC 也正常（G1，年轻代停顿 <50ms）。怀疑是 controller 与某些 broker 之间的 group coordinator 元数据同步滞后——也就是俗称的"幽灵会话"：某个 broker 上残留了过期会话，controller 恢复后把它判死、再复活、再判死，形成循环。

【已尝试】

1. 把 session.timeout.ms 从 45s 拉到 90s，周期从 ~90s 变成 ~180s，没有根治；
2. 升级 client 从 3.2 到 3.4，配合 broker 侧 group.version=V2，仍复现；
3. 抓取 broker 端 group-coordinator-metrics，发现 GroupCoordinator 的 LastError 周期性出现 UNKNOWN_MEMBER_ID；
4. 重启 controller 所在 broker 后现象消失约 10 分钟，之后再次复发。

【期望答案】

1. 如何在不重启集群的前提下，确认到底是"幽灵会话"还是别的（比如网络分区、GC 长暂停）？需要看哪些 broker/client 指标，阈值大概是多少？
2. 有没有生产上验证过的根治配置组合（session.timeout/heartbeat.interval/group.min.rebalance.delay 的具体数值与依据）？
3. 如果必须走升级路线，Kafka 哪个版本开始对 group coordinator 的会话恢复有明确修复（commit 号或 release note 链接）？
4. 过渡方案：能否用 ConsumerRebalanceListener 做"软恢复"，减少全组重入的代价？请给出具体的 listener 实现要点。