cask/artifact/moved: use mv instead of cp and rm

[bevanjkay]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

As mentioned internally, this PR is an attempt at trying to use mv to backup cask artifacts on upgrade/reinstall instead of using cp and rm.

[Copilot]

Pull Request Overview

This PR refactors the move_back method in the Moved artifact class to use mv instead of cp followed by delete, making the uninstall process more efficient and atomic. However, there is a critical bug in the implementation.

Key Changes

• Replaced /bin/cp -pR target source with /bin/mv target source.dirname
• Removed the subsequent delete(target, ...) call (no longer needed with mv)
• Removed blank line after the move operation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The change from cp to mv with source.dirname as destination will not correctly restore the artifact if the target basename differs from the source basename.

For example, if a cask specifies a custom target name:

• source in staging: OriginalName.app
• target installed: /Applications/CustomName.app

The original code would copy to the exact source path: cp -pR /Applications/CustomName.app /path/to/staging/OriginalName.app

The new code moves to the parent directory: mv /Applications/CustomName.app /path/to/staging/ which results in /path/to/staging/CustomName.app (wrong basename).

Consider using mv target source instead of mv target source.dirname to preserve the exact source path.

Suggested change

	args: [target, source.dirname],
	args: [target, source],

[MikeMcQuaid]

Makes sense to me, good to merge when 🟢, thanks!

[bevanjkay]

I don't believe that this change is possible due to a couple of technical constraints;

1. The permissions model of mv is substantially different to cp and would require us temporarily modifying permissions before reinstating them, which I don't feel is a good idea.
2. An earlier PR adjusted the method of upgrade to only replace the contents of an application to retain certain quirks with the way app removal interact with the dock, and some extended attribute behaviours.