up_thru解决先后宕机与同时宕机的歧义

Monitor 按 epoch 轮询检测 OSD 状态，存在一个天然盲区：如果 A、B 两个副本几乎同时故障，Monitor 可能先在某个 epoch 检测到 A 宕、B 还活着，下一个 epoch 才检测到 B 也宕了——但这个”B 还活着”的中间状态到底是真的（B 期间可能接受了新写入，之后恢复的 A 数据不全，必须等 B）还是 Monitor 检测滞后的假象（B 其实早就一起宕了，A 的数据完好，不需要等）,单看 epoch 记录根本无法区分，会导致系统在完全不需要等待时也保守地等待。up_thru 的解法是让每个 OSD 完成 [[Peering建立PG级数据一致性窗口|Peering]] 后主动向 Monitor 上报”我在哪个 epoch 完成了 Peering、真正开始能接受写入”，之后重新 Peering 时通过检查这个值就能准确判断该副本在故障前是否真的进入过可写状态，而不必依赖 Monitor 自己滞后的故障检测时序。这个案例说明：分布式系统里”观测到状态变化的时间点”和”状态变化实际发生的时间点”可能存在偏差，关键决策不能直接依赖观测时序，必须让当事方主动上报确定性事件。