cask/artifact: don't copy xattrs when quarantine is unavailable

[aholland]

Following on from #23608, which fixed a defect I had recently introduced in #23556 by failing to guard a call to Quarantine.detect. Upon discovering my mistake, I checked every other call site of the Quarantine methods that raise where there is no quarantine support, and found one existing instance of the same defect: two call sites in download.rb and one in audit.rb were already guarded (#23229), two in upgrade.rb were guarded by #23608, but one in moved.rb was unguarded. This PR addresses that defect.

When an install or upgrade reuses an existing target directory — the adopt/overwrite path, and ordinary upgrades, which keep the app directory in place — Moved#move copies the source's extended attributes with Quarantine.copy_xattrs. That method is implemented in the macOS extension only; the base module raises NotImplementedError, so on Linux the install dies mid-move. The fix guards the call with Quarantine.available?, as the module's other call sites do. As with #23608, I have not seen this reported — reaching it needs a cask installed on Linux — so this is closing a latent hole rather than fixing a live crash.

To reproduce, on a system without quarantine support, with any installed app cask:

brew upgrade --cask <token>
Error: <token>: NotImplementedError

Details

What does the test assert? That the reused-directory reinstall completes without Quarantine.copy_xattrs being called when Quarantine.available? is false. Verified red before the change (the unguarded call fires) and green after. Same shape as the regression tests in #23229 and #23608.

Why Quarantine.available? rather than an OS check? It is the guard the module's other call sites use, and it also covers the macOS degenerate case of a broken xattr, where the rest of the quarantine machinery (propagation, the upgrade snapshot) is already skipped — copying quarantine xattrs for an install that was never quarantined would do nothing useful.

• Have you followed our Contributing guidelines?
• Have you checked for other open Pull Requests for the same change?
• Have you explained what your changes do? Performance claims (e.g. "this is faster") must include Hyperfine benchmarks.
• Have you explained why you'd like these changes included, not just what they do?
• For bug fixes, have you given step-by-step brew commands to reproduce the bug?
• Have you written new tests (excluding integration tests)? Here's an example.
• Have you successfully run brew lgtm (style, typechecking and tests) locally?

---

• I did not use AI/LLM to create this PR, or I disclosed the tool/model below and reviewed its output; I did not attribute commits to AI and will answer maintainer questions and review comments myself without AI/LLM.

Used Claude Code (Fable 5) to investigate and draft; I directed the investigation, and reviewed the diff and every line of this PR text.

---

[MikeMcQuaid]

Thanks!