[BUG] Cowork: "Change location for Cowork files" copy fails outright, and partial copy flattens nested subfolders into destination root

What's Wrong?

Attempted the workaround suggested in #71307 for the "overlaps a protected host location" mount-refusal bug — changing Settings → Cowork → Cowork files to a location structurally unrelated to the existing workspace. This produced a third, distinct failure mode not yet documented in #71307, #78368, or #69329.

Environment: Windows, Claude Desktop, Cowork.

Steps to Reproduce:

1. Existing Cowork files location: C:\Users\<user>\Documents\Claude (contains subfolders including scripts\, Outputs\engine-state\, Artifacts\, Backups\, populated with real working files — this is the same folder blocked from mounting per #71307).
2. Settings → Cowork → Cowork files → Change location → select a new, empty, structurally unrelated folder (e.g. C:\Users\<user>\Documents\CoworkFiles).
3. Confirm.

What Happened:

• App immediately surfaced: Couldn't copy your Cowork data to the new location. See logs for details.
• The Cowork files setting did not switch — Settings still shows the original path after the failure, so the app did not end up pointed at a broken copy. (This is the one thing that worked as expected.)
• The destination folder was not left empty despite the reported failure — it contains a partial, structurally incorrect copy: two correctly-nested top-level folders (Artifacts\, Backups\) sit alongside a flat pile of loose files whose canonical location is nested subfolders of the source — e.g. .gso_interactive_unlock (normally lives in scripts\) and multiple BACKLOG.md.bak.* / AUDIT_DIRECTIVE_* files (normally live in Outputs\engine-state\) — all dumped directly into the destination root instead of into their corresponding subfolder. This suggests the copy routine mishandles nested directory traversal and the reported failure may be a direct consequence of that mishandling, not a generic permission/disk-space error.
• App's own logs (main.log, cowork_vm_node.log under %APPDATA%\Claude\logs\) do not appear to tag this operation distinctly — could not isolate the relevant log lines from the general activity stream to attach here.

What Should Happen?

• The copy operation should either fully succeed (preserving directory structure) or fully roll back on failure — never leave a partial, structurally-scrambled copy at the destination.
• The confirmation dialog / failure message should point to a specific, filterable log file or log tag for this operation, not just "see logs" with no further guidance.
• Given #78368 already reports this same flow copying 12.87GB including credentials to an unsafe world-readable location with zero warning, and this report adds a distinct hard-failure-with-corruption mode, the "Change location" copy implementation itself may need a broader review rather than three separate point fixes.

Related: #71307 (root-cause mount-refusal bug this workaround was attempting to route around), #78368 (unsafe successful copy), #69329 (copy leaving app in a broken self-referencing state).