feat: collect CPU temperature from DGX Sparks

[0xdfi]

Summary

DGX Spark nodes now report CPU temperature through the existing remote CPU metric instead of always returning 0. The collector reuses the host sensor allowlist and priority order, while filtering unrelated NVMe and network-card sensors.

Related: #34

Validation

• node --test server/collectors/__tests__/SystemCollector.cpuTemp.test.js - 8 passed, including the full remote DGX Spark parse path
• npm run typecheck - passed
• npm run build - passed
• Code review completed with no remaining actionable findings.

Post-Deploy Monitoring & Validation

• Search logs for Remote CPU error during the first 15 minutes.
• Compare the API CPU temperature with the first allowed hwmon or acpitz sensor on one DGX Spark.
• Healthy signal: a plausible non-zero Celsius value updates with each normal CPU poll.
• Failure signal: CPU polling fails, temperature exceeds the accepted sensor range, or the value comes from an NVMe/CX7 sensor. Roll back this PR if observed.
• Validation window and owner: first 15 minutes after deployment; sparkDash maintainer/operator.

---

[MiaAI-Lab]

Thanks @0xdfi — the collector approach here is the right one (same hwmon allowlist as hosts, NVMe / CX7 filtered out).

We're not merging this as-is: Spark pages and Overview still gated CPU temp to kind: host, so the new reading would never show on DGX Sparks. The thermal glob as the last SSH command could also fail the whole CPU poll if no zone matched.

Took that sensor path in #70, wired Overview + the Spark GPU panel, and hardened the SSH command with || true. Closing this as superseded by #70.