fix(s3): honest per-source versioning across backends and multipart-upload leak sweep

[pmaxhogan]

Closes #220 (part 2). Closes #222.

#220: per-source versioning now really keeps versions on S3 and local folders

Versioning was honestly gated OFF on those destinations (part 1, v2.5.0) because their object id is derived from the file name: the executor versions a change by forcing the CREATE path, which there lands on the SAME object, so the retained file_versions row ended up pointing at the bytes that had just been overwritten. This is part 2 - making it work rather than making it unavailable.

The seam is one trait method, defaulting to today's behaviour:

async fn archive_version(&self, file_id: &str, content_token: &str)
    -> anyhow::Result<Option<String>>;   // default: Ok(None)

None = "no archival needed here", which is Google Drive (its create already mints a new object and the old one survives in the trash). Some(id) is where the superseded bytes now live, and the version row points there.

• driven-s3 copies the object server-side into <root>.driven-versions/ - a plain CopyObject, or ranged UploadPartCopy above S3's 5 GiB single-copy ceiling. No bytes pass through the process.
• driven-localfs copies data + sidecar into .driven-versions/, mirroring the live tree so a user browsing the drive can see which file an old copy belongs to.
• SFTP stays gated off, honestly. It has the same path-keyed model but no server-side copy, so archiving a version would mean re-uploading the whole file over the link that is already the bottleneck. Shipping that silently would double the cost of every changed file.

Three properties are load-bearing, and each has a test:

1. Deterministic archive id, a pure function of (object, content token) - the token being the OLD plaintext BLAKE3 the executor already had.
2. Never re-copy over an existing archive. An op can die between the archive and its commit and be replayed, by which time the live object may already hold the NEW bytes; a blind re-copy would overwrite a correct archive with the content it exists to preserve. Together with (1) this also stops a replay stacking copies.
3. trash is a no-op for an archived id. After a versioned change the executor "trashes" the object the version row names, meaning "out of the live tree, still restorable" - which is what Drive's trash does and what the archive already did. On these stores trash is a PERMANENT delete, so without this it would destroy the version just recorded. delete_permanent (the count-cap prune) still frees it.

The version store is invisible to the folder picker and excluded from list_source_object_ids, so neither the remote-existence audit nor the integrity scrub sees an archived version as an orphan to heal forever. LocalFsStore::about() still counts its bytes as Driven's footprint - they are real storage a versioning setting is spending.

When the copy fails, the upload proceeds as a plain in-place update and no version is recorded: a certain loss (this backup does not happen) must not be traded for a hypothetical one. But it is not silent - a new drive.version_archive_failed Warn row lands in the activity log, because a destination quietly not delivering the point-in-time restore its settings page offers is the #220 bug one level down.

Executor delta (additive; coordinated with the team lead since PR1/PR2 also touch this file): one field on VersionSupersede, one optional JSON field on PendingOpPayload (supersedes_archive_file_id - unmigrated; an older row without it decodes as None, pinned by a test), one call site after resolve_version_supersede, and the two NewFileVersion construction sites reading the archive id. supersedes_drive_file_id deliberately keeps naming the ORIGINAL object, because that is what the pre-flip file_state row points at and what every recovery guard compares against.

#222: abandoned multipart uploads no longer leak

upload_stage_resumable opened a fresh CreateMultipartUpload on every attempt, so a retry abandoned the previous upload id with nobody holding it. Its parts stayed on the bucket - billed, invisible to ListObjectsV2 - one per failed attempt, forever.

New RemoteStore::abandon_resumable_session is a real AbortMultipartUpload on S3 (a no-op default elsewhere), called wherever a session becomes permanently unreachable:

• a fresh session replacing a persisted one,
• an invalidated session discarded before a restart,
• a streaming upload whose pending op is about to be DELETED,
• every path by which reconcile's resume_persisted declines to resume (a changed file, an expired session, an encrypted source, a misbehaving server) - funnelled through one wrapper so a new decline condition cannot forget.

It deliberately does NOT fire on the Fatal mid-stream path, which keeps the op precisely so the session can be RESUMED; aborting there would turn a recoverable upload into a full re-send. crash_mid_upload_resumes_persisted_session_byte_for_byte pins that, and caught an earlier, broader version of this change.

S3Store::sweep_abandoned_multipart_uploads adds the backstop: ListMultipartUploads + abort, spawned detached when the store is built (account assembly must not wait on a network round trip to a possibly-unreachable endpoint). Three guards, unit-tested as a pure function because an over-eager abort destroys a live transfer: prefix (a shared bucket keeps its own uploads), ownership (never an upload id this process opened), and age (7 days, longer than the 6-day persisted-session window, so it can never kill a session anything would still resume; an upload the server did not date is skipped rather than guessed at).

The chaos harness keeps a BOUNDED stranded-upload assertion rather than zero, with the old "unfixed finding" note replaced by an accurate one. The residual case is structural, not a missing hook: reconcile is a per-process STARTUP pass, while a scan later in the same run re-plans the failed path under a new op - so an upload kept on purpose for a crash-resume can be overtaken mid-run and sits until the next start, where reconcile now either resumes it (no waste) or aborts it. Bounded by restarts, not unbounded in time, with the sweep behind it.

Docs

• README footnote 42 rewritten (the old text claimed versioning is Drive-only), plus a new S3 housekeeping paragraph covering the .driven-versions prefix and a lifecycle-rule recommendation for incomplete multipart uploads, and the local-folder "no trash" bullet corrected to distinguish deleted from changed files.
• design/DESIGN.md §5.5.1's "Destination restriction" section replaced with the capability + archive_version design.
• design/ROADMAP.md backend item updated.
• UI: versionRetention.s3 / .local_folder copy rewritten, errors.drive.version_archive_failed added, fixtures flipped to match the real descriptors, gating tests re-pointed at SFTP, plus new tests asserting the POSITIVE direction (an S3 source DOES get the versioning editor and the point-in-time restore picker).

Verification (all run, real results)

Suite	Result
cargo test --workspace (excl. e2e/bench)	all green, incl. 560 driven-core and 442 driven-app
cargo clippy --workspace --all-targets -- -D warnings	clean
cargo fmt --all --check	clean
driven-s3 e2e vs local MinIO	pass
driven-s3 e2e vs live Cloudflare R2	pass
driven-localfs e2e	pass
chaos scenario run-all	74 PASS / 31 SKIP / 0 FAIL
pnpm -C ui run test:unit	791 passed (59 files)
pnpm -C ui run lint	0 errors
just e2e (containerized app-level)	9/9 PASS

The S3 e2e suite gained a section that drives the whole #220 round trip against a REAL server - archive, overwrite, prove the archive still holds the OLD bytes, prove it is invisible to the picker and the audit, prove trash does not destroy it and delete_permanent does - plus a #222 section for abandon + sweep. Both MinIO and R2 pass it, which is what validates the hand-built CopyObject / UploadPartCopy / ListMultipartUploads requests (rusty-s3 models none of the three).

just e2e passes 9/9 (wizard-first-run, local-folder-round-trip, settings-persistence, fake-drive-outage-surfaced, source-file-unreadable, dest-disk-full, s3-round-trip, s3-network-cut-mid-sync, sftp-round-trip).

One gotcha worth knowing for anyone else running it locally: it first failed to COMPILE on a reason unrelated to this branch. The Dockerfile's --mount=type=cache,target=/build/target cache mount was serving a stale driven-remote rlib that cargo treated as fresh, so driven-s3 and driven-core rebuilt from this branch while driven-remote did not, and the build died with "method archive_version is not a member of trait RemoteStore" while cargo check --workspace was clean on the host. The Docker CONTEXT was correct (the new symbols are present in a throwaway image built from it) and touching source mtimes, including into the future, did not bust it. docker builder prune --filter type=exec.cachemount -f then a cold build fixed it. CI starts cold and is unaffected, but a local run after a branch that changes a low-level crate's public API can hit this and it looks exactly like a broken branch.

🤖 Generated with Claude Code

https://claude.ai/code/session_019xKUm9vH4ifb5LHR5szy1v

[github-actions]

Coverage

Area	main	this PR	delta
Rust (lib crates)	84.51%	84.44%	-0.07 (OK)
UI (vue/ts)	93.37%	93.37%	+0.00 (OK)

Gate: passed - no coverage regression (epsilon 0.1 pp).