Notification content lists a temperature breach at exactly the threshold, inconsistent with the incident-driving check

**Describe the bug**

`NotificationMessageBuilder.extractThresholdBreaches` reports a temperature breach with `maxTemp >= threshold`, while `StatusService.computeHardwareStatus` — the check that actually drives the "breached" status transition and incident creation — uses a strict `maxTemp > threshold` for the same comparison (as do cpu, memory and disk in both files; temp is the only metric where the two files disagree).

**To reproduce**

1. A hardware monitor has `tempAlertThreshold: 80` and is already `breached` for some other reason (say `cpuAlertThreshold` exceeded).
2. A check reports `cpu.temperature: [80]` — exactly at the threshold, not over it.
3. `StatusService` correctly does not count temp among the breaching metrics (`80 > 80` is false).
4. `extractThresholdBreaches`, called separately to build the notification content, evaluates `80 >= 80` as true and lists temperature as a breaching metric in the alert.

**Expected behavior**

Temperature exactly at the threshold should not be reported as a breach, matching cpu/memory/disk's own boundary behavior and the status-transition check for the same metric.

PR with the one-character fix (`>=` → `>`) plus a regression test coming right after this.

Start with NotificationMessageBuilder.extractThresholdBreaches and compare its temperature threshold check with StatusService.computeHardwareStatus. Change the boundary behavior to match the status check, then add the regression test described in the issue and verify that an exact-threshold temperature is not listed as a breach.

Written by the indexing model from the issue text.