bundle: try mas install before falling back to mas get

[wojteksbt]

---

• 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? Performance claims (e.g. "this is faster") must include Hyperfine benchmarks.
• Have you written new tests (excluding integration tests) for your changes? Here's an example.
• Have you successfully run brew lgtm (style, typechecking and tests) with your changes locally?

(Ran components individually: brew tests --only=bundle/mac_app_store --no-parallel 14/14 pass, brew style no new offenses, brew typecheck clean. This is the byte-identical diff already validated for #22271.)

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes. Non-maintainers may only have one AI-assisted/generated PR open at a time.

AI (Claude Code) drafted the patch and RSpec test based on issue #22270, which I authored after manually reproducing the regression on a fresh macOS 26.5 install. I verified the empirical reproducer myself (mas get <id> fails where mas install <id> succeeds for a purchase-history app not on disk). Tests, style, and typecheck were run locally before pushing. No prior AI-assisted PR is open (#22271 is closed).

---

What this fixes

Fixes #22270.

This re-submits #22271 against main. #22271 was opened against master (stale fork default) and merged there, but the merge-queue protection rule on main rejected the propagation, so the fix never reached main. @MikeMcQuaid asked for a fresh PR with base=main so it can go through the merge queue cleanly (#22271 comment). The diff is unchanged.

PR #21590 switched brew bundle from mas install to mas get based on the assertion in #21559 that they're equivalent for already-purchased apps. Empirically on macOS 26.5 / mas 7.0.0 this isn't true — mas get returns No downloads initiated for ADAM ID <id> for apps in the Apple ID's purchase history but not present on disk, while mas install succeeds for the same id in the same session.

This adopts the fallback strategy from the #21559 body that wasn't taken in #21590:

Try mas install first (fast path for already-associated apps). Fall back to mas get if install fails with the redownload error.

Both scenarios are now covered: purchase-history restore (install succeeds, get not called) and fresh Apple Account (install fails, get takes over).

cc @rgoldberg @MikeMcQuaid

[MikeMcQuaid]

Thanks!