Resolve downloads from the release list when latest 404s

[nnmarcoo]

Closes #55.

/releases/latest skips prereleases. Every tag is a -pre-alpha, so it 404s and the per-platform download menu has never rendered on bloomview.rs. Confirmed live:

/releases/latest      -> HTTP 404
/releases?per_page=10 -> HTTP 200

Nothing looked broken because .catch(() => {}) leaves the plain Download button pointing at /releases, which is why this sat unnoticed.

Falling back to the release list turned out to be the wrong fix on its own. I ran the patched resolver against the live API and it cheerfully resolved this:

resolved release: v0.4.7-pre-alpha
  Windows   img_0.0.1_x64_en-US.msi
  macOS     img_0.0.1_x64.dmg
  Linux     img_0.0.1_amd64.AppImage

Those are the archival releases from the old app. A visitor would have been handed a February build of a different program under a Download button. That is worse than the button doing nothing.

So the fallback also requires assets named bloom-*, which every artifact release.yml produces already is, and skips any release carrying none. Behaviour I verified:

situation	result
only archival releases (today)	no menu, Download falls through to /releases
first real release, archival tags still present	picks it, full variant per platform
newest release is a draft	skipped, picks the one below
a non-prerelease exists	/releases/latest hits, fallback never runs

The bloom- prefix is the load-bearing part. If artifact naming ever changes in release.yml, this needs to change with it, and the comment in the file says so.

Touches docs/index.html alongside the #62 PR, but different hunks.

[nnmarcoo]

Closing unmerged. The fallback solves a problem that goes away on its own.

/releases/latest only 404s because every tag so far is a prerelease. Cutting a public release fixes it, and the existing resolver already picks the right asset per platform from a real release payload, full variant, ignoring a checksums file.

It is also mildly counterproductive. A rate-limited 403 lands in the .catch, so the fallback fires a second request that is also rate limited and also fails. Two failed requests instead of one, plus a hard dependency on the bloom-* artifact prefix in release.yml.