[violetaGitHub]

What does this pull request do?

Loading an xlink's files, as it's created or with Load its files, shows the progress an update or a switch shows.

Current behavior

The card said "Loading its files" with no bar for as long as the files took to load.

Behavior with this pull request

The card shows the files and bytes downloaded and a percentage, as a switch does. When changes had to be put aside first, its steps are "Putting your changes aside", the load with its bar, and "Bringing your changes back".

How it was implemented

• loadXlinkArgs runs cm update <folder holding the xlink> --forcedetailedprogress --noinput --dontmerge instead of --machinereadable, which turns cm's progress bar off. Its line is read by readUpdateProgress, as for update and switch (context.progressOf).
• Updating a folder, cm acts on pending changes as client.conf's PendingChangesOnSwitchAction says, which may be to shelve them itself; --machinereadable used to turn that into a refusal. Now loadXlink reads the pending changes first (a local cm status) and clears them before the update, as a switch does (switchApproach): unchanged checkouts undone, a merge in progress refused, other changes shelved, undone and merged back after the load (loadAroundChanges, reason 'xlink'). Private files don't count.
• Dropped: keeping --machinereadable and counting its per-item lines (no totals, so no bar); putting changes aside only on cm's refusal (localized words, and no bar).

Behavior changes

• With cm's default settings, pending changes are now put aside and merged back while an xlink's files load, where cm alone would have left them in place. The app can't tell, as it never reads cm's config. If they don't merge back cleanly, "Welcome back" offers them, as before.
• A failure of cm update with changes pending now says what went wrong, instead of being taken for cm's refusal.

Checklist

• npm run typecheck and npm test pass (8,455). New tests: the update runs with --forcedetailedprogress and reports readUpdateProgress's progress; over a workspace whose cm update refuses while changes are pending, the app never updates with changes in the way (changes aside first, merged back; a private file isn't put aside; a failure before shelving loads nothing and leaves the changes).
• Seen in the app (development build, scripts/sandboxes/xlinks.sh with a 4,000-file xlinked repository, README.md pending, cm set to Shelve): the card went from "Putting your changes aside" through "Downloading … files" 1% → 93% to "Bringing your changes back"; files loaded; README.md stayed pending; clean console. Only the progress card changed, so one theme.
• npm run e2e: not run; smoke loads no xlinks.
• Other areas: none; create and Load its files both go through loadXlink.
• Reviewed in a clean context: no must-fix. Added a test that the reported progress is the update's; load closes over its context; the rejected alternative in the docs reworded. Kept: no Cancel on the card, as creating or loading an xlink isn't cancellable (the card shows Cancel only for cancellable operations).
• docs/features/xlinks.md describes the progress, why changes are cleared first, and the alternative dropped.

Fixed issues

None.

🤖 Generated with Claude Code