Sparkle 2.8.1 (the previously pinned version) does not parse
sparkle:hardwareRequirements — that element was added in
sparkle-project/Sparkle#2797 and first shipped in Sparkle 2.9.0.

Without this bump, the multi-item appcast generated by the parent
commit would still serve Intel Macs the arm64 ZIP, because 2.8.1's
SUAppcastDriver.filterSupportedAppcast performs no CPU/hardware
filtering and bestItemFromAppcastItems breaks ties by first item —
which is the arm64-restricted entry.

2.9.0 changelog is additive (markdown release notes, signed feeds,
hardwareRequirements, minimumUpdateVersion); 2.9.1 adds bug fixes
and SKIP_INSTALL=YES for XPCServices. No API removals that affect
this codebase. Sparkle.xcframework's internal layout
(Versions/B/Autoupdate, XPCServices/*.xpc, Updater.app) is unchanged,
so scripts/sign-and-notarize.sh's discovery logic continues to work.
SparkleUpdater.swift typechecks against 2.9.1 against the new
NS_SWIFT_UI_ACTOR annotation on SPUUpdaterDelegate.

Refs: https://github.com/sparkle-project/Sparkle/releases/tag/2.9.1

The structural appcast fix and Sparkle 2.9.1 bump only take effect
after a user is running a cctop build that ships Sparkle 2.9+.
Intel users currently on cctop v0.15.2 (which bundles Sparkle 2.8.1)
will still be handed the arm64 ZIP by the in-app updater on the
release that finally fixes them — because the resolution happens in
the *currently-running* Sparkle, not the one inside the new download.

Add an FAQ entry in both README.md and site/index.html walking
affected Intel users through a one-time manual download of the
x86_64 DMG to get over that bridge. After the manual upgrade,
subsequent updates will pick the correct architecture automatically.