fix(upload): a stuck attachment can always be removed, and closing the peek no longer strands one

[Dygreens]

The report

I want to upload pictures but something [was] preventing me from uploading pictures last time so I re-uploaded them except I can't hit send because there are still pictures that seem to be trying to upload and no delete button. No remove button no way for me to send this prompt.

Root cause — two defects that compound

1. Cancellation was inferred from array membership. uploadAndAttach decided "did the user remove this chip?" by asking peekFiles.indexOf(placeholder) >= 0. But _peekFilesStash swaps peekFiles wholesale when the peek closes or switches worker — so closing the peek mid-upload read as a removal. The transfer was abandoned and the placeholder was left sitting in the stashed array at 0%, with nothing left to drive it.

The artifact confirms it: four empty .chunked-* dirs in ~/.amux/uploads. /api/upload/start had succeeded; chunk 0 never wrote. That is the signature of the loop bailing at i = 0.

2. The escape hatch existed only in the success state. The chip rendered its × inside the done branch, so the one state where you need it most — an upload that never finished — had no remove control at all. sendPeekCmd() refuses while any chip lacks a .path, so a single stranded chip made the composer permanently unsendable.

The fix

• Cancellation is an explicit flag + AbortController, not array membership. The upload no longer cares which array it currently lives in: close the peek, switch worker, reopen — it still lands on its path.
• The × renders on every chip in every state.
• A failed upload keeps its chip with a retry, instead of being spliced out behind one toast (which silently lost the file). The original File is retained so retry is real.
• _peekFilesRestore marks an orphan (no path, not in flight) as failed, so it presents as something to act on rather than as frozen progress.
• The send guard names the file and says what to do. "Wait for upload to finish" is a lie when nothing is transferring — it is what kept the user waiting on an upload that was never going to complete.
• The >12-file summary row surfaces a failed count; past that threshold chips are collapsed, so a blocker could otherwise sit behind a row that only reported progress.
• Server: sweep orphan .chunked-* dirs by mtime. The in-flight map is in memory, so every restart orphaned its tmpdirs with no record left to purge them by.
• Mobile: 44px-tall chip controls, per the project rule.

Verification

e2e/upload-chip-escape.spec.ts drives the real functions against a stalled upload, because the bug only exists while a transfer is in flight — a test using an instantly-completing file passes against the broken code.

	pre-fix	post-fix
in-flight chip can be removed	❌	✅
closing the peek does not strand it	❌	✅
failed upload keeps chip + retry	❌	✅

Control run with product code reverted to the parent commit and the spec kept: all three fail. Against the fix: 9/9 pass on desktop, mobile and ios-safari. npm run lint:spa clean (0 errors, verified the gate still fails on an injected undefined name); cargo check and cargo clippy -p amux-server clean.

Logged in frustrations.md as AMUX-85, plus AMUX-86 for a separate instrument defect found on the way in.

🤖 Generated with Claude Code