huangzd1997
3137299bfe
线上任务 28459（外观专利）三个分片的载荷对象被删、DB 行仍指向已删的确定性 key，组装读不到 → 整单 FAILED。数据其实还在同槽位的版本化对象里，是行指错了。 三条收口： - 上传补偿删除加准入：只有末段带 UUID 的版本化 key（本次写入独占）才允许入队。 确定性 key 会被重传复用，删它就删掉了行仍在引用的对象；而删除队列 （deleteObjectFromRetry -> removeObject）本身不做引用反查，准入必须卡在入队处。 - 引用守卫阈值 >1 收紧为 >0：原来把「恰好 1 行引用」当作调用方自己那行而放行， 但调用方无法证明归属。物理删除本就约定在 DB 行删除之后执行，正常路径引用数 必为 0；宁可留孤儿（有保留期清理兜底），也不删可能仍被引用的对象。 - chunk 读兜底：指针对象确已缺失（NoSuchKey）时回退同槽位版本化对象 chunk-N-*。 仅限 chunk 槽位 + 确为缺失两个条件，避免误配无关对象或掩盖真实故障。 测试：新增 31 个用例（补偿删除准入 / 引用守卫 / 兄弟对象兜底），均先确认 RED 再实现；另更新 3 个断言旧行为的既有用例。全量 mvn test 3082 个 0 失败。