Avoid content duplication

Find and clean up duplicate content:

Help me find and clean up duplicate content in our Juno library. Start read-only: find and confirm the duplicates first, and change NOTHING until I approve each action. Judge by the content, never by the title.

═══ SCOPE ═══
Ask me in one message: the whole library, or one area (a channel, a topic, a content type). Confirm the scope, then pull the units in scope with read tools only (search_lms_content, list_channels, get_channel_content, list_unit_children) and tell me how many you found.

═══ FIND, THEN CONFIRM BY READING ═══
Group likely duplicates by topic, title, or overlapping subject. Then open each candidate and read it (read_unit_text, read_unit_content_blocks). Distinguish:
- True duplicates: the same content, one or more redundant copies.
- Overlapping but different: related content that should stay separate, and why.
- Versions: an older and a newer take on the same thing.

═══ THE REPORT ═══
Show me clusters, ranked by how much they overlap. For each: the units in it by name and type, where each is used (channels, journeys, assignments), how they actually differ, which one is the KEEPER and why (most complete, freshest, most used), and what unique content the others hold that the keeper is missing.

═══ ONE PROPOSAL PER CLUSTER ═══
For each cluster, one recommendation with its trade-off:
- MERGE: fold the unique parts into the keeper, then retire the rest.
- RETIRE: take specific redundant units out of use, keeping the keeper.
- UNLINK: remove a redundant unit from a channel or journey without deleting it.
- KEEP BOTH: reading showed they are not duplicates; say why.
Before proposing retire, check where the unit is used and flag any live channel, journey, or assignment that still depends on it.

═══ EXECUTE ONLY WHAT I APPROVE, ONE CLUSTER AT A TIME ═══
Use the platform's own actions where they exist: merge through an approved change plan on the keeper, unlink from channels and journeys (remove_channel_content, remove_unit_child), update card details (update_unit_metadata). Where an action has no path from here, such as archiving or deleting a unit, do not force it: give me the exact steps to finish it in the Juno admin, and mark it pending on my side. Confirm what changed after each cluster, and finish with the tally.

Rules throughout: read-only until I approve; every duplicate confirmed by reading; usage shown before anything is retired; merge before retire so nothing unique is lost; nothing changes without my explicit yes per cluster.