Rework /try and /try/download for two platforms

[joemasilotti]

The Android demo app is live on Play (see #63), but the try funnel is still iOS end to end.

/try (app/views/pages/try_it.html.erb) has an Apple logo in the primary CTA, a "Download on TestFlight" label, and screenshot captions like "powered by iOS 26 Liquid Glass." /try/download is a two-step TestFlight walkthrough: its title, meta description, and h1 subtitle all say "on your iPhone in two steps," and both cards branch on ios_request?.

For 0.11.0 the Android demo was added to /try/download as a single secondary link rather than restructuring either page. That is deliberately a stopgap.

The asymmetry worth designing around

The two install paths are genuinely different shapes, so mirroring the iOS layout onto Android would be wrong:

	Steps
iOS	3: install TestFlight, open the join link, install Ruby Native
Android	1: open the Play listing, Install

Android ships on Play's Open testing track, so the plain store listing works with no opt-in URL and no tester list. There is no TestFlight-equivalent prerequisite to explain.

Open questions

• Does a signed-in Play user see a plain Install button, or an early-access / join-testing interstitial first? The unauthenticated listing HTML has no such banner, but it is a JS-rendered page so that is not proof. Needs one real-device check before any copy promises one tap.
• What happens after a good Android demo? Today the customer Android build funnel is still pre-GA behind /android-beta, so there is a real risk of landing someone in a waitlist right after the demo sells them.
• There is no android_request? helper yet; ios_request? lives at app/helpers/application_helper.rb:65. QR codes are useless to a visitor already on the target device, which is what that helper exists to handle.

Measurement

The secondary link fires the Fathom event try: android demo download. That is the cheap proxy for whether this rework is worth doing, so let it collect before committing to the redesign.

[joemasilotti]

Two things from the issue body are already done, so scratch them from the scope:

• android_request? now exists in app/helpers/application_helper.rb, next to ios_request?.
• The Android card on /try/download has a QR code.

Worth carrying into the redesign: the QR sits beside the Play link there rather than replacing it, which is deliberately different from the iOS cards above. Play's web listing can remote-install to a signed-in device, so a desktop click is a real install path on Android in a way it isn't on iOS. Any two-platform layout should preserve that rather than flattening both platforms into the same QR-or-link branch.

[joemasilotti]

Correction to my previous comment: android_request? was added and then removed, so it does not exist. Treat that bullet as still open.

The reason it came out: on the /try/download Android card it was doing nothing but hiding an already-collapsed "Show QR code" toggle. The iOS cards branch on ios_request? because they swap the primary CTA between a tappable link and a QR-gated flow, which is substantive. The Android card swaps nothing, so the check bought one hidden line of text in exchange for user-agent sniffing that ios_request? itself documents as unreliable.

If the two-platform rework does need device detection, add it then, for a case where it changes the primary action rather than a secondary affordance.