fix(uploads): make execution attachment completion replay-safe - #6601

Summary

• finalizeExecutionAttachment reported a completedFileId. That marker is what routes a replayed completion into loadCompletedUploadPurpose, which handled only workspace_file and threw a bare Error otherwise — unclassified, so the route rendered a generic 500. Its structurally identical twin finalizeMothershipAttachment correctly reports nothing.
• Both are metadata-backed and idempotent by storage key — exactly what the finalizeUploadPurpose TSDoc already states — so neither needs the marker. Dropped it from the execution finalizer so the twins agree.
• loadCompletedUploadPurpose is now an exhaustive switch, matching the sibling finalizeUploadPurpose switch, so adding a purpose is a compile error until its replay behavior is decided rather than a runtime 500. The residual arm throws a classified UploadSessionError('internal') instead of a bare Error.
• markUploadSessionCompleted no longer clears a marker it was not given. A finalizer that records one inside its own registration transaction (markUploadSessionFileRegistered does this for workspace_file) would otherwise have it overwritten with null — and both the abort guard and the expiry sweep key on it: cleanupExpiredUploadSessions only treats a finalizing session as disposable when completedFileId is null. No-op for every current path, since markUploadSessionCompleted moves the session to completed, which is neither abortable nor a cleanup candidate.

Latent only. No shipped client replays a completion: the sole producer, uploadWorkflowAttachments, mints a fresh session per file and never retries; requestJson does not retry; a concurrent double-submit is already a clean 409 from claimSession. Nothing is mutated on the failing path.

Not a parity regression — the whole upload-session plane is new on staging (uploadSession does not exist in main's schema). This is new code not meeting its own documented contract: the plane's README states that sessions in domain finalization are retained "for an idempotent completion retry".

Type of Change

• Bug fix

Testing

bun run type-check clean. 2053 tests pass across app/api/files, lib/uploads, lib/knowledge, lib/table — the last three being the other completeUploadSession consumers. bun run lint and bun run check:api-validation pass.

Tests pin the invariant rather than the symptom: a Record over the purpose union is a compile-time gate on which route each purpose replays through, and the cases assert that idempotent purposes report no marker and reject cleanly if they ever reach the loader. Verified they fail — restoring the marker turns the execution_attachment case red; dropping a purpose from the table fails the gate.

Follow-ups (deliberately not in this PR)

A DRY pass over the wider plane found real, pre-existing duplication that this change does not touch and should not be bundled with a latent-bug fix:

• service.ts: the lease-scoped WHERE predicate written 9×; the release-lease-on-failure catch 4× (two byte-identical); the terminal status-transition UPDATE 3×; deleteOwnedFinalObject is a strict prefix of discardIncompleteProviderState.
• provider.ts: the 3-way provider branch re-opened in 7 exported functions (21 copies of create<P>Config), with GCS as a silent fallthrough in 5 of them.
• application.ts: completeWorkspaceUploadSession writes the same reauthorize call 4× where its internal twin extracts one authorize closure.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)