Attach tray: re-attaching the same file stops stacking duplicate chips

[DaveTseng2019]

The bug

Drop or paste a file that lives outside the workspace, then do it again. You get two chips:

foo.png    (≈1.2k tok)
foo-2.png  (≈1.2k tok)

Same file, same bytes, two copies in .claude\attachments\, two at_mentioned sends, two of the 20 tray slots gone. Do it a few times while iterating on a screenshot outside the repo and the tray fills with clones of one file.

The tray already dedupes — but only references (WasCopied=false). Out-of-workspace files come in as staged copies, and the comment on that path said copies are always distinct files so they never match. True for a pasted screenshot; not true for a file the user handed us twice.

The fix

Match on the original path + its last-write time (FindBySource), checked before any copying happens. A repeat re-mentions the chip that already exists — exactly what clicking the chip does.

The timestamp is deliberately part of the key: a staged copy froze the old bytes, so a file edited since it was staged must still come in as a new attachment. That is usually the reason someone attaches the same path a second time.

Placed ahead of the BMP branch as well, so re-dropping a .bmp finds the PNG transcoded the first time instead of transcoding it again.

Unchanged on purpose:

• Pasted screenshots and composer text still never dedupe. No source file, so each one is genuinely new content.
• Ranged mentions stay separate attachments. Program.cs#L10-20 and #L30-40 are different things.
• In-workspace references behave as before (they now short-circuit one step earlier, same outcome).

Verification

Release build clean. Manually: drop a desktop file on the panel twice → one chip, two @-mentioned lines in the feed. Save the file, drop again → a second chip appears, which is the intended escape hatch.

CLAUDE.md's attachment paragraph is updated — the old sentence ("copies never dedupe") is no longer accurate.

🤖 Generated with Claude Code

[firish]

Merging - this is a genuine data bug and the diagnosis is exactly right, including the part where my comment on that path was the misleading bit. "Copies are always distinct files" is true of a pasted screenshot and false of a file handed to us twice, and I wrote it without noticing the difference.

Two things I want to credit specifically. The timestamp in the key is what makes this correct rather than merely convenient: a staged copy froze the old bytes, so a file edited since staging has to come in fresh, and that edit is usually the whole reason someone attaches the same path again. And placing the check ahead of the BMP branch means a re-dropped .bmp finds the PNG you transcoded the first time instead of transcoding it again - easy to miss, and it would have been a subtle waste.

Verified against the built assemblies in a throwaway workspace rather than by reading: outside file dropped twice = one chip; edited then dropped again = a second chip; in-workspace file twice = one chip, still WasCopied=false so the source is never deletable; the same image pasted twice = two chips, since contentless pastes have no source to match on. All five as designed.

One maintainer tweak on the branch, and it came out of reviewing your change: checking whether a capture's empty SourcePath could ever match a real file (it cannot) showed that StageCapturePng still used the old inline trim from before #36, so a screenshot arriving at a full tray could evict a still-pending mention - the exact invariant AddItem exists to protect. Routed through AddItem, and the empty SourcePath is now documented as deliberate.

Thanks Dave - and thanks for correcting the CLAUDE.md sentence rather than leaving it wrong.