fix(web): send mobile invitees to the app stores, not GitHub releases

[TheSeydiCharyyev]

Summary

An invite link opened on a phone offers github.com/block/buzz/releases — a list of desktop binaries. normalizeOperatingSystem folds every non-desktop user agent into unknown, assetPattern has no pattern for unknown, and resolveBuzzDownloadUrlForPlatform therefore falls back to the releases page.

That fallback was the right answer while there was no mobile app to point at. Both listings are live now, so this classifies iOS and Android as real platforms and resolves them straight to their store URL, ahead of the GitHub release lookup:

• iOS — https://apps.apple.com/us/app/buzz-chat-with-your-hive/id6779728271
• Android — https://play.google.com/store/apps/details?id=xyz.block.buzz.mobile

Verified both listings resolve, and that the Play Store id matches namespace = "xyz.block.buzz.mobile" in mobile/android/app/build.gradle.kts.

iPadOS in desktop mode (MacIntel + maxTouchPoints > 1) is classified as iOS rather than being discarded — the App Store listing reports iPad support. ChromeOS and Fire tablets (kindle/silk) keep the releases fallback on purpose: neither is served by the Play Store listing. Desktop detection is untouched, so macOS, Windows and Linux still resolve a release asset exactly as before, including the "which Mac do you have?" flow.

This is the store-links half of #3357 only. That issue also reports a blank render of the invite page on iOS Safari against a self-hosted relay. I could not reproduce that and it is not addressed here — the invite page renders the download link unconditionally, so the two symptoms do not share a cause.

Related issue

Refs #3357 (partial — see the scope note above). No open PR touches web/src/shared/lib/buzz-download.ts or web/tests/e2e/smoke.spec.ts; #2255 is the closest, adding a "Browse releases" link to the same invite page.

Testing

web package, node 22.17.1, pnpm 11.4.0.

The existing e2e case invite download falls back for mobile and non-desktop devices pinned the releases-page fallback for iPhone, iPadOS desktop mode, Android and ChromeOS. It now carries an expected destination per device, covers a Fire tablet too, and is renamed to invite download sends each non-desktop device where its app lives.

Reverting only the buzz-download.ts change fails it exactly as reported in the issue:

Error: iPhone Safari
expect(locator).toHaveAttribute(expected) failed
Expected: "https://apps.apple.com/us/app/buzz-chat-with-your-hive/id6779728271"
Received: "https://github.com/block/buzz/releases"

With the change, all six smoke tests pass, including the desktop download assertion and the Mac-choice dialog. pnpm check and pnpm typecheck are clean.

Platform classification was also exercised directly against real user-agent strings — iPhone Safari, iPadOS desktop mode, Android Chrome (with UA client hints) and Android Firefox (without) all classify as ios/android, while macOS, Windows, Linux, ChromeOS and Fire tablet keep their previous classification.