id(web): image upload stores by filename with no collision handling — a second paste named 'image.png' silently un-names the first #1549

Problem

POST /api/upload stores every image under its multipart filename as a blob tag, with no collision handling — so a second upload that arrives under the same name silently re-points that name to the new blob, and the first image disappears from every name-based surface. Uploaded names collide in ordinary use, because they are not unique:

• Paste/drop File names are caller/browser-assigned, not unique per image (a clipboard bitmap is image.png). The web upload path sends the File as-is (uploadImageFile, web/src/image-upload.ts:76: formData.append("file", file) — no filename argument), so the multipart filename the server reads is exactly file.name.
• The server's own fallback for a nameless upload is paste-{unix_seconds}.{ext} (src/web/routes.rs:1491-1499) — one-second granularity, so two nameless uploads in the same second also collide.
• The client's dedicated pasted-image name, generatePasteFilename (web/src/image-upload.ts:57-60, `paste-${Date.now()}.${ext}`), is never sent to the server at all — it is only the alt-text fallback at image-upload.ts:217. It has the same shape of problem anyway: millisecond-only entropy.

Evidence (verified this run, main a120b9a9)

Laptop Bun 1.4.2 probe (real image-upload.ts, sha256 d0ab2a43 identical both sides; probe + log in the goal's hidden_files/probe-2026-10-27-laneA-uploadname/):

• P1 fixed-clock: call1=paste-1730000000000.png call2=paste-1730000000000.png identical=true
• P1 tight-loop: 200 calls -> 1 distinct name(s)
• P2 paste#1: bytes=3 -> server sees filename="image.png" and P2 paste#2: bytes=4 -> server sees filename="image.png" — two different images present the same filename on the wire, which is the name upload_handler keys on.

Server chain, by code read (src/web/routes.rs):

• :1491-1499 — filename = field.file_name() when non-empty (reconciled with the content type at :621), else paste-{secs}.{ext}.
• :1553 — state.store.tags().set(tag, hash) with Tag::from(filename): a bare overwrite of any existing tag of that name. No existence check, no uniquifying, no archiving.
• :1562/:1575/:1588 — the created (set_if_absent), modified and content-type metadata tags are also keyed by that same filename, so the second upload's metadata merges into the first image's name record.
• images_list_handler (:1613+) lists images by tag, and get_file_name (:1015+) resolves a hash's name by tag — once the tag is re-pointed, the first image is gone from the image browser/list and from name lookup, even though its blob and any /blob/{hash} embeds keep working (which is why this stays silent).

Contrast with the house pattern: FileOps::rename/copy archive whatever they replace (src/fileops.rs:15-16, archive_existing at :153 — <name>.archive.<unix-ts>). Upload is the outlier: it is the one name-writing path that destroys the previous occupant without a trace. A document save overwriting its own name is intended semantics; an image upload is the creation of a new object, so the replace semantics do not transfer.

Why it matters

Pasting two screenshots into documents is a core editor flow. Today the second paste quietly un-names the first image: it vanishes from the image browser, name-based lookups return the newer image, and the shared metadata record mixes both uploads. Nothing errors anywhere, so the loss is only noticed when someone goes looking for the earlier image by name.

Acceptance criteria

• Two uploads that arrive under the same filename both remain listed by images_list_handler and resolvable by name afterwards — e.g. the later upload is uniquified (suffix/counter/hash-derived) or the replaced name is archived first, per the fileops pattern; triage picks and pins one behaviour.
• The nameless-upload fallback name cannot repeat for two uploads in the same second (and, if the client paste name is ever sent, generatePasteFilename gets the same guarantee).
• Regression coverage in the existing upload router tests (upload_router_tests, src/web/routes.rs:2333+): two same-name uploads with different bytes → both images still listed/resolvable, first upload's name record not silently merged with the second's.
• No change to document save semantics (a save still updates its own name's tag) and no change to the /blob/{hash} URL shape.

Notes

• Not a duplicate of id(web): image upload completing after the document shrinks is silently lost — stale insert position throws, success logged as failed #1379 (upload completing after the document shrinks — insert-position, client side) or id(web): /blob serves any blob as text/html via the ?filename= parameter — no CSP/nosniff/disposition headers (same-origin XSS by link) #908 (upload filename/type reconciliation — the reconcile_upload_filename step above is untouched by this).
• Deliberately not self-solved by the filing lane: the fix is a naming-semantics decision on the upload path (uniquify vs archive-first) that interacts with the image browser and metadata tags — queue-lane triage should pin it.