fix(desktop): retry a transient update-check failure once before surfacing it

[Adarsh-Me]

Summary

Fixes #4790's user-visible failure mode: the startup update check intermittently surfaces "检查更新失败 / Cannot parse releases feed" when GitHub transiently answers electron-updater's releases-feed request with HTTP 406 and an empty body — the identical request succeeds seconds later, so the first failure is noise, not an outage.

AppUpdateService.checkForUpdates now retries once after a two-second backoff (on the injected clock). While the retry is pending, the error listener holds a check failure back instead of publishing it, so a transient refusal never reaches the renderer as an error state or toast; a retry that also fails publishes exactly as before. Download and install errors are unchanged — they surface immediately. dispose() clears the retry timer alongside the schedule timer.

Two scope notes from #4790:

• The stale Maka-Agent/maka-agent publish config is already fixed on main (electron-builder.config.mjs publishes to owner: apache, repo: maka); the stale app-update.yml only exists inside installed v0.1.11 packages and is replaced by the next install. This PR therefore changes only the failure handling.
• Nightly snapshots stay off the stable "latest" semantics via the existing allowPrerelease channel gating, unchanged here.

Verification

• biome check on both changed files: clean.
• Targeted tsc --strict pass over app-update-service.ts: no errors beyond missing-node_modules artifacts (NodeJS namespace, setImmediate), which the workspace toolchain supplies.
• The two new regression tests in app-update-service.test.ts cover both paths: a first-attempt 406-style failure (error emitted and thrown, as electron-updater does) that recovers on retry with no error status ever published, and a persistent failure that surfaces exactly one error status after two checkForUpdates calls. Full file: 17/17 pass. Run standalone with tsx --test against real electron-updater@6; the workspace test pipeline will re-run it under CI.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope:

Checklist

• Tests cover the change and fail without it — without the retry, the first new test fails with a published error status and a single checkForUpdates call; the second fails with zero error statuses published.
• Lint, format, typecheck and the affected suites pass locally — see Verification; full Desktop suite runs in CI.

Does this PR entail a change in behavior?

• No — a transient check failure that recovers now resolves silently instead of surfacing as an error; persistent failures behave exactly as before.