Find near-duplicate photos: give the grouping the image index already computes a place in the UI #360

What's missing. The image index can already group near-duplicate photos, but nothing in the app or MCP can reach it. "Which of these 40 burst shots and re-exported copies can I drop?" is one of the most common reasons people open a file manager on a photo folder, and the hard part is already built.

What exists.

• media_index_dedup_clusters(volume_id, threshold) returns DedupCluster { paths } groups (two or more images each) whose feature-print cosine is at or above the threshold (default 0.9, commands/media_index/search.rs). It reads the resident vector cache, works while the drive is offline, and leaves out excluded folders.
• Per-image "Find similar images" already ships as a button on each tile in Search's image results grid (search.imageResults.findSimilar), so the grid, the thumbnails, and the "why this matched" reasons are in place.
• The command sits on the desktop-ipc-unused allowlist until this lands (docs/notes/ipc-dead-code-audit.md).

How I'd surface it.

1. Entry points, scoped to where the person already is:
   • Folder context menu: Find duplicate photos (that folder and everything under it).
   • Command palette: "Find duplicate photos in this folder" (the focused pane's folder) and "…on this drive".
   • In Search's image results, a Duplicates toggle beside the existing image filters, which groups the current results instead of ranking them.
2. Results in the pane, the way search results open in the pane today: one block per group, thumbnails side by side, each with name, size, pixel dimensions, date taken, and folder. Sort groups by how much space dropping the extras would free, biggest first, and show that figure per group ("Free up 48 MB").
3. Keep one, mark the rest. Cmdr preselects a "keeper" per group (highest resolution, then the earliest date taken, then the shorter path, preferring anything outside Downloads) and marks the others with the normal selection. The person reviews, moves the keeper with the keyboard if they disagree, and presses F8. It's the existing trash flow, so it lands in Trash and shows in the operation history with rollback. ❌ Never delete anything automatically.
4. One similarity control: a three-step "Exact copies / Very similar / Similar" segment, mapping to thresholds around 0.97 / 0.92 / 0.87. A slider over cosine numbers would mean nothing to people. Default to "Very similar".
5. Honest coverage: only indexed images can be grouped, so reuse the coverage note ("Checked 12,345 of 20,000 photos here; the rest are still being indexed").
6. MCP: a find_duplicate_photos tool (scope, similarity, and limit), returning groups plus the suggested keeper. "Clean up my duplicate photos" becomes an agent task with the person approving the trash step.

Recommendation: ship 1 (the context menu and palette entries), 2, 3, and 5 first. The Search toggle, the similarity control, and MCP can follow.

Open questions for David.

• Folder scope needs a path-prefix filter over the volume-wide grouping. That's cheap, but check the grouping's cost on a 100k-image drive first: it may need to run in the background with progress and Cancel, per "everything cancelable".
• Should "Exact copies" mean byte-identical (size plus a hash, computed only within candidate groups) rather than a very high threshold? It's more honest wording, with a small extra cost.
• Should groups ever span drives (the same photo on the laptop and the NAS)? That's a bigger feature, and probably later.

Origin: the IPC dead-code audit, 2026-10-03.