fix(api): send required User-Agent on GitHub release requests

[Jeccoman]

Summary

The /api/releases route fetched the CPU and GPU latest releases from the GitHub REST API without a User-Agent header. GitHub requires a User-Agent on every request and rejects requests that omit it with 403 Forbidden — with or without an auth token. So these two lookups silently failed and the downloads page fell back to null for the CPU/GPU miner releases whenever the response wasn't served from an intermediate cache.

lib/clientRelease.ts already sent the header correctly, which is why the client-app release kept working while the CPU/GPU releases didn't — the two code paths had drifted despite doing the same job.

What changed

• New lib/github.ts — a single hardened GitHub release client that:
  • always sends the required User-Agent (plus Accept + API version),
  • attaches the server token when present and transparently retries once anonymously on 401/403, so a bad/expired token can't take down an otherwise-public lookup,
  • returns a structured { ok, status, data } result instead of throwing, with cache: 'no-store'.
• pages/api/releases.ts and lib/clientRelease.ts now both use it, removing the duplicated request logic that allowed the drift.

Why this way

The bug existed because the same request logic was implemented twice and one copy was missing a header. Fixing it in one place and routing both callers through it prevents the class of bug, not just this instance.

Testing

• npx tsc --noEmit — no new type errors (pre-existing .svg module-resolution errors are unrelated).
• npx next lint on changed files — clean.
• npm run build — succeeds; /api/releases compiles.

Risk

Low. No API surface or response-shape change ({ cpu, gpu, client } unchanged). Behavior only improves on the previously-failing path. No new dependencies.