fix: resolve default version via npm latest dist-tag (#3)

## Summary

- The homepage default path (no `?tag=` query) used to hit `GET
/releases?per_page=10` and return the first release with matching
installer assets, which could miss or mis-order the intended channel.
- Resolve the default version via npm's `latest` dist-tag first
(vite-plus 0.1.17 now ships under `latest` and includes the Windows
installer), then fetch that specific tag from GitHub. Added
`DEFAULT_DIST_TAG = "latest"` and generalized
`fetchLatestVersionFromNpm` → `fetchNpmDistTagVersion(distTag)`.
- On failure in the default path (incl. GitHub 404 when npm/GitHub are
momentarily out of sync) return `null` rather than `"not-found"` so
`getRelease` doesn't poison `release:latest` with a 5-minute negative
cache — the stale-cache / `buildReleaseFromTag` fallbacks still apply.
- Users who want a specific alpha build can still pass
`?tag=v0.1.17-alpha.5`.

## Test plan

- [x] `vp check`
- [x] `vp test` — 24/24 passing, including 4 new default-path cases for
`fetchRelease`:
  - [x] success: npm `latest` → GitHub `/releases/tags/v<version>`
  - [x] npm 503 returns `null` and skips GitHub
  - [x] npm missing `latest` dist-tag returns `null` and skips GitHub
  - [x] GitHub 404 on resolved tag returns `null` (not `"not-found"`)
- [ ] Manual smoke test on `vp dev`:
  - [ ] `/` with no query renders v0.1.17 (current `latest`)
  - [ ] `?tag=v0.1.17-alpha.5` still renders that specific release
  - [ ] `?arch=x64` (no tag) 302-redirects to the v0.1.17 x64 installer
  - [ ] `?tag=does-not-exist` still returns 404

Author: fengmk2

package.json

@@ -10,7 +10,7 @@
     "@types/node": "^25.5.2",
     "vite": "catalog:",
     "vite-plus": "catalog:",
-    "void": "npm:@void-sdk/void@0.2.6"
+    "void": "npm:@void-sdk/void@0.3.0"
   },
   "packageManager": "pnpm@10.33.0"
 }