fix(clone): Git LFS clones succeed or open with the real LFS error

[danielss-dev]

Closes DAN-80.

Root cause (confirmed)

A local LFS fixture with filter.lfs.required=true and an unreachable LFS URL reproduces Daniels’ toast exactly:

Error downloading object: asset.bin (…): Smudge error: … batch response: Post "http://127.0.0.1:1/info/lfs/objects/batch": connection refused
error: external filter 'git-lfs filter-process' failed
fatal: asset.bin: smudge filter lfs failed
warning: Clone succeeded, but checkout failed.

git clone did fetch Git objects. Checkout then ran Git LFS smudge, the download failed, and Git aborted the working tree. Strand treated that as a failed clone, so there was no usable repo.

error_summary kept only lines starting with error: / fatal:, so the toast showed the smudge lines and dropped Git LFS’s Error downloading / batch response: explanation.

A second documented failure mode (Git LFS 3.5 installing hooks during smudge vs newer Git clone protection) is the same class of bug: smudge during clone can abort checkout. Skip-smudge covers both.

Hypothesis 3 (missing git-lfs) is also covered: with skip-smudge plus disabled filter.lfs.*, clone no longer dies as a filter failure; if the tree has LFS files and git lfs version fails, the user is told Git LFS is not installed.

Not confirmed from here: Azure DevOps auth on Daniels’ private portal-setup (no access). The failure shape matches LFS smudge abort during clone checkout; creds vs missing object vs LFS URL is what the new error text will distinguish on his machine.

Approach

Reuse, don’t redesign Clone/LFS dialogs.

• clone_with_options still uses clone_args (branch / depth / single-branch / blob:none / recurse / -- / validate_remote_arg unchanged).
• Clone process: GIT_LFS_SKIP_SMUDGE=1 (inherited by recursive submodule clones) and -c filter.lfs.process= -c filter.lfs.smudge= -c filter.lfs.required=false so a missing git-lfs binary cannot abort checkout.
• After a successful clone, complete_clone_lfs: if HEAD has LFS paths, git lfs install --local then git lfs pull, same progress/cancel handle.
• Success: real working-tree bytes, clean status.
• LFS step failure or cancel: still return CloneOutcome.path so Strand opens the repo; warning carries the full Git LFS transcript plus “Git LFS → Download and check out objects”.
• error_summary keeps LFS explanation lines, not only error:/fatal:.
• Clone failure popup wraps and scrolls (pre-wrap, max-height) instead of a 5-line clamp.

Proof

• crates/strand-core/tests/clone_lfs.rs
  • local bare repo with LFS objects → clone_with_options checks out real contents (not pointer text), status clean
  • missing LFS objects → usable repo + warning containing missing object / Failed to fetch some objects, plus retry hint
• error_summary_keeps_git_lfs_explanation_lines uses a transcript shaped like the portal-setup toast
• Local: cargo test --locked -p strand-core (235 lib + clone_lfs/clone_scope/clone_recursive/sparse_checkout), cargo clippy -p strand-core -- -D warnings, pnpm --filter ./ui exec tsc --noEmit, pnpm --filter ./ui test (584)
• GitHub CI on this PR (all green): Frontend (tsc + vitest), Rust (test + clippy) on ubuntu-22.04 and macos-latest, Azure DevOps Server helper (Windows), Native agent review (Windows)

Live check still needed on Daniels’ machine

Cannot reach private portal-setup / Azure DevOps from CI.

• Clone portal-setup in Strand on Windows
• Confirm OnPremiseInstallation/rustfs/rustfs.exe is the real binary, status clean
• If LFS auth/URL still fails: repo should open, popup should show the real Git LFS/Azure error (not only smudge filter), retry via Git LFS → Download and check out objects
• Confirm Git LFS is on PATH in the Strand process (same as system Git)

Do not merge until that live check (or an explicit skip) is done.