Stop DedupConversationFilter from keeping retweets of mid-thread replies

[Pitchfork-and-Torch]

DedupConversationFilter keys replies by min(ancestors) and ancestor-less retweets by get_original_tweet_id(). That only collapses a retweet of the root. A retweet of a mid-thread reply keys to the reply id, so the RT and the rest of the thread both survive post-selection.

Proof

• Entry: DedupConversationFilter::get_conversation_id (phoenix post-selection)
• Sink: For You TopK after VF; one kept post per conversation_id
• Break: RT of reply 11 with ancestors [2, 1] keys to 11; the reply keys to 1
• Viewer: a viral reply-RT and another post from the same thread both take For You slots
• Twin: existing tests already collapse RT-of-root (retweeted_tweet_id == min(ancestors)); Thunder fills ancestors on replies, not on retweets

This is not #97/#102 (gap expansion / unhydrated grandparents). Not #99 (self-reply chains). Not #101/#111 (muted/blocked ancestors). Not #179 (seen/served parent). Not #180 (Phoenix VF parents).

Fix: map each slate tweet and ancestor onto the smallest conversation root already present. Ancestor-less retweets use that root when the original is on the slate as a reply or as someone's ancestor. Unrelated originals stay on their own tweet id. Replies still key by min(ancestors), so shallow [2] vs [2, 1] stay two conversations.

One file on current main. Replaces contaminated #189 (19 files, behind main).

Tests: RT of the reply itself, RT of a reply listed as a sibling ancestor, unrelated RT unchanged, existing root-RT and multi-conversation cases unchanged.

cargo test cannot run here. Public dump has no Home Mixer manifest. Standalone rustc model of old vs new keying passed 5/5.

[Pitchfork-and-Torch]

Parking this intern-stack PR per operator GitHub cleanup (2026-09-08). Hunt notes remain local. Not a reject of the class.