fix(website): download gate never enables when the GitHub API lookup fails

[felipesalinasr]

Before merging / deploying

• No secrets or config needed: the deploy workflow now passes the built-in github.token to the build (no new repo secret).
• Note: after merge, the website build FAILS CLOSED if the latest-release lookup fails, instead of shipping a page with a dead download button. That is intentional; re-run the deploy if GitHub hiccups.

The bug (user-reported)

Invited users paste the correct code and the download button never enables; clicks do nothing.

The button required both a code match and a successful runtime fetch of api.github.com/.../releases/latest from the visitor's browser:

• Unauthenticated GitHub API = 60 requests/hour per IP. Shared IPs (offices, VPNs, mobile carrier NAT) get refused -> no installer URL -> button can never enable.
• The fetch had no .catch; blocked/failed lookups fail silently and permanently.
• Validation only ran on input events, so a code pasted before the fetch resolved stayed locked even after the URL arrived.
• UX hid it: the input turns green (code accepted) while the button stays at 35% opacity with pointer-events: none.
• Analytics hid it too: download_unlocked only fired on the happy path, so affected users were indistinguishable from visitors without a code.

The fix

Plan A (live, upgraded): the runtime lookup stays, now with .catch + re-validation when it lands (fixes the paste-before-fetch race).

Plan B (baked fallback): new src/_data/release.js resolves the latest installer URLs at build time and bakes them into the page. If the live lookup fails, the baked link downloads the app directly. Worst case: the release current at deploy time, and the app self-updates on first launch. Nothing hand-written, nothing version-pinned in source.

Gate rule change: a correct code alone unlocks the button; the href is live-or-baked. Same for the Windows modal and the early-access page (whose fallback previously dumped users on the homepage).

Hardening: case-insensitive code check; autocapitalize="none" autocorrect="off" on both inputs (iOS typed Getsh*tdone and never validated); download_unlocked fires on code match unconditionally; download events carry link_source: live|baked so the fallback path is measurable.

lib/release-assets.js holds the pure asset-picking logic outside _data — Eleventy treats named exports in data files as data keys and silently drops the default export (verified the broken build output before moving it).

Verification

• pickInstallerUrls unit-checked via node against the real v0.4.27 asset list + empty/undefined inputs.
• Eleventy build bakes real URLs into /, /early-access/ (en/es/pt).
• Playwright against the built site with the API endpoint deadened: wrong code stays locked; correct code (mixed case, padded) enables Mac + both Windows buttons with direct installer hrefs; console warning surfaces the lookup failure.
• Race test: code typed immediately on load unlocks instantly and stays unlocked after the fetch settles.
• CI fail-closed: CI=1 + failing lookup throws (tested with a 401).
• Biome clean on both new JS files.

🤖 Generated with Claude Code