[jammsen]

Closes #233

What

The GPU temperature Health finding fired at fixed 85/90 °C (TEMP_WARN / TEMP_CRITICAL in server/health/HealthEvaluator.js). Both are now settings, following the shape agreed in the issue.

• Settings: healthTempWarnC and healthTempCriticalC, defaults 85 and 90, so behaviour is identical until someone edits them.
• Validation: each must be a number from 40 to 110 and warn must be lower than critical. PUT /api/settings refuses anything else with a 400 and saves nothing. A hand-edited settings.json with unusable values falls back to 85/90 together.
• Evaluator: reads the limits on every sample (via a thresholds option on HealthEvaluator, wired to getSettings() in SparkMonitor), so a change applies on the next sample without a restart. The finding detail shows the configured values.
• Alerts and Activity: both reuse the finding, so they follow the configured limits with no change of their own.
• UI: a "GPU temperature alerts" row in Settings with two °C inputs and a Reset to Defaults button. The dialog checks the same rules before saving. English and 简体中文 strings added.
• Docs: README settings table row and a CHANGELOG entry.

Per-unit overrides are left for a later step, as agreed.

Notes

• The limits are always in °C, whatever the display unit; the label says so.
• The 40–110 °C range is my choice; the issue only said "sensible range". Happy to change it.
• The 简体中文 text should be checked by a fluent speaker.
• Existing Activity events keep their old text ("warns at 85°C"); only new events use the configured values.

Testing

npm run typecheck, npm run build and npm test pass (1331 server, 720 frontend). New tests cover the evaluator, settings validation and fallback, SparkMonitor Activity events with non-default limits (including a live change), and the dialog (save, refusal of bad input, reset). I also tried the dialog in a running instance.

[MiaAI-Lab]

Reviewed and ported: now on main as 36d3567, 9407d41 and 3ad5ddc, with your authorship (cherry-picked with -x) and a CHANGELOG credit. All three commits were needed — the tip alone does not apply — and they went in cleanly on current main. I verified the parts that matter rather than taking the description on trust: the three new threshold tests fail against the unchanged evaluator, updateSettings is reached before the merge so a bad patch persists nothing (server/settings.js:329), and the existing PUT /api/settings handler already turns that throw into a 400 (server/index.js:760-777), so your claim holds without touching the route. _clampSettings falling both values back together is the right call for a hand-edited file, since it cannot leave warn above critical.

The 40–110 °C range is fine as proposed. The thresholds callback reading getSettings() on every evaluation is also the right shape — it keeps one evaluator per unit and applies a change on the next sample, as agreed in #233. Full suite on Linux after the port: 1331 server and 732 frontend tests pass, typecheck and build clean. Thank you for the patience with the issue thread, and for matching the agreed scope exactly, including leaving per-unit overrides out.

(Review notes prepared with Claude Code on behalf of the maintainer.)