feat: say when a newer release is out #90

Nothing tells you today that a newer release is out.

Plan

• nodkey version prints nodkey X.Y.Z on stdout as now. Then it asks GitHub for the newest release, for 10 seconds at most, and prints one line on stderr. The line gives one of three things:
  • a newer release: its version, its release page, and sudo nodkey update (feat: install script and nodkey update #88);
  • "this is the newest release";
  • why it could not check.
    --offline skips the check. A build from the source does not check. The exit code stays 0 when the check fails.
• Broker: it asks GitHub at the start and then every 24 hours. When a release newer than its own version is out, it sends one silent Telegram notice per new version and broker start. The notice has the version, the release page and the steps: nodkey update as root, then systemctl restart nodkey. The link is built from the version. Never take a URL or text from the answer.
• Config: [updates] check = true by default. check = false turns the broker's check off.
• Owner decision, 2026-10-17: the broker's Telegram notice and nodkey version.
• The lookup: GET https://api.github.com/repos/code6x/nodkey/releases/latest, with no login and User-Agent: nodkey/<version>.
  • It goes through HTTPS_PROXY like the calls to Telegram, with TLS 1.2 or newer, no redirects, a time limit, and a cap on the body (1 MiB).
  • Read only tag_name, and skip a draft or a prerelease. Accept only vX.Y.Z with numbers in range, and compare as numbers.
  • A newest release that is older than this version is not a notice. Never suggest a downgrade.
  • Rate limits (403 or 429) and other errors give one journal line and no notice. Try again next time.
• The check never affects a request. It runs on its own and stops with the broker, in the fixed order of DESIGN.md section 15. Its notices use the same rule as feat: warn when the client and the broker run different versions #89: they never use up the limits for "never ask" notices.

Done when

• nodkey version works as above. Tests use a fake server: a newer release, the same, an older one, a bad tag, 403 and 429, a time-out, a body that is too big, and a redirect that is not followed.
• The broker's check works as above. Tests show one notice per new version, and none when nodkey is up to date, after an error, or with check = false. The broker still stops cleanly. (After the review: the first check comes 10 minutes after the start, not at once, so a broker in a restart loop sends no notice.)
• No test reaches the real network, and the end-to-end test does not either.
• DESIGN.md (sections 7, 14 and 15), THREAT-MODEL.md and docs/setup.md are updated, with the new config key and a note on firewalls and proxies. The threat model says that the broker now talks to api.github.com. A fake answer can only cause a wrong notice, and the update still checks the attestation.