Kafka 重复消费时幂等表挡不住的外部副作用（下游 API 调用 / 通知发送）你们怎么兜底？

【背景】 我负责一条订单履约链路，Kafka 3.5（3 broker，ISR=3），topic order-fulfill 24 分区，消费组 8 实例，at-least-once。单条消费逻辑分四步：

1. 查幂等表（MySQL 8.0，唯一索引 biz_id）判断是否已处理；
2. 写业务表（订单状态流转）；
3. 调下游 WMS 接口触发拣货（HTTP，无本地事务保护）；
4. 调 SMS 网关发送用户通知（HTTP，无本地事务保护）。 最后提交 offset。

【现象】 去年两次 rebalance 窗口期（实例 GC 导致 session 超时被踢出组），出现了 37 条消息被新实例重新消费。幂等表成功拦住了第 1~2 步的重复写入，但第 3 步 WMS 接口被重复调用了 11 次（下游按 request_id 幂等，所以没出错），第 4 步 SMS 通知被重复发送了 37 条——用户收到 2 条甚至 3 条"您的包裹已发出"短信。

核心矛盾：幂等表是"写之前查"，天然挡不住"写成功之后的副作用已经产生"这个窗口。尤其当下游 API 的幂等粒度（如 WMS 按 request_id）和我们消息的业务粒度（如 order_id）不一致时，幂等表甚至可能"放行"一条业务上不该重复的调用。

【已尝试】

1. 给 SMS 网关加了 5 分钟频控（同一 order_id 5 分钟内只发一次）——解决了大部分重复，但 5 分钟窗口内的"合法重试"（如用户投诉后人工重发）也被拦住了；
2. 把第 3、4 步改成异步事件（写一张 outbox 表，另一个 worker 轮询发送）——逻辑上更干净，但引入了新的延迟（轮询间隔 2s）和新的故障点（worker 挂了通知就积压）；
3. 下游 WMS 侧要求我们带 idempotency_key，但他们的实现是"同 key 直接返回缓存结果"，无法区分"首次调用"和"重试调用"，日志上看不出来。

【期望得到的答案形态】

• 你们在生产中怎么区分"幂等放行"和"副作用已产生"这两种情况？有没有比"频控 + outbox"更优雅的模式？
• 如果下游 API 不支持 idempotency key 或支持得不彻底，消费端有没有通用手段（如"副作用日志表"、"调用前预占位"）来做到可审计、可重放？
• 有没有团队把"第 3、4 步"拆成独立 topic 让另一个消费组处理，用"消费组 A 提交 offset = 副作用完成"来保证不丢不重？这种做法的延迟和运维成本你们觉得值不值？