Disk health rules: a spec catalog and alerts only on what the drive itself reports #10464

Part of #10352 (parked twice as one piece; this is its first third). Pure data in, plain data out: no route, no page, no I/O.

Done when:

• [x] src/machines/disk_catalog.ts: a small checked-in catalog keyed by model, starting with Samsung SSD 980 PRO 1TB: 600 TBW, 5-year warranty, composite temperature warning 82 °C and critical 85 °C. An unknown model returns null; nothing is guessed.
• [ ] src/machines/disk_health.ts: parseSmartJson(text) turns smartctl --json -a output into { model, firmware, capacityBytes, dataUnitsWritten, bytesWritten, percentageUsed, availableSpare, spareThreshold, mediaErrors, criticalWarning, temperatureC, warnTempMinutes, critTempMinutes, powerOnHours, unsafeShutdowns } or a named refusal for bad input; a device behind a RAID controller (PERC / megaraid, no NVMe health log) parses as { kind: "behind-controller" }, never as an SSD.
• [x] assessDisk(reading, previous?, spec) returns { level: "ok" | "alert", reasons: string[] }. It alerts only on: a critical-warning bit set, spare below its threshold, percentage used ≥ 80, media errors higher than the previous reading, or minutes above critical temperature higher than the previous reading. Everything else is ok.
• [x] test/disk-health.test.ts with four recorded fixtures under test/fixtures/smart/ (healthy: the 11-09 reading in #10352, 550 GB written, 0% used, 39 °C, 2,575 h, 41 unsafe shutdowns; worn: 82% used; hot: critical minutes rising; failing: critical warning bit + spare below threshold) plus a PERC virtual disk. Each rule has a test that fails without it, and 41 unsafe shutdowns alone is not an alert.

Files: src/machines/disk_catalog.ts, src/machines/disk_health.ts, test/disk-health.test.ts, test/fixtures/smart/*. Touch nothing in src/http or src/web.

Parked by the crew: the check stayed red through 2 automatic tries (pull #10471 closed; its branch torque/10464-disk-health-rules-a-spec-catalog-and-ale at dac67c1a356f keeps the work so far). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Reviewed pull #10616 at its head: ticked src/machines/disk_catalog.ts: a small checked-in catalog keyed by model, starting with Samsung SSD 980 PRO 1TB: 600 TBW, 5-year warranty, composite temperature warning 82 °C and critical 85 °C. An unknown model returns null; nothing is guessed.; assessDisk(reading, previous?, spec) returns { level: "ok" | "alert", reasons: string[] }. It alerts only on: a critical-warning bit set, spare below its threshold, percentage used ≥ 80, media errors higher than the previous reading, or minutes above critical temperature higher than the previous reading. Everything else is ok.; test/disk-health.test.ts with four recorded fixtures under test/fixtures/smart/ (healthy: the 11-09 reading in #10352, 550 GB written, 0% used, 39 °C, 2,575 h, 41 unsafe shutdowns; worn: 82% used; hot: critical minutes rising; failing: critical warning bit + spare below threshold) plus a PERC virtual disk. Each rule has a test that fails without it, and 41 unsafe shutdowns alone is not an alert..

Left open after pull #10616 landed: 1 unticked item remains (src/machines/disk_health.ts: parseSmartJson(text) turns smartctl --json -a output into { model, firmware, capacityBytes, dataUnitsWritten, bytesWritten, percentageUsed, availableSpare, spareThreshold, mediaErrors, criticalWarning, temperatureC, warnTempMinutes, critTempMinutes, powerOnHours, unsafeShutdowns } or a named refusal for bad input; a device behind a RAID controller (PERC / megaraid, no NVMe health log) parses as { kind: "behind-controller" }, never as an SSD.). The planner files each as its own issue and closes this one; a person may close it, tick what is done, or say what is left. Until then the crew does not pick it again.

The open box is on main: src/machines/disk_health.ts exports parseSmartJson and parses a device behind a controller as behind-controller. Closing.

Already done on main in cf39091f5: the remaining box landed there (see my comment above).

Planner: the one open box (parseSmartJson, plus behind-controller for a RAID device) is on main in cf39091f5, so I am not opening new work for it. The forge would not let me close it: a planner cannot close as done without the forge-written note, and cannot drop it because a person asked for it. A person can close it.

The open box is shipped: parseSmartJson with the named refusals and { kind: "behind-controller" } for a PERC disk landed on main in cf39091f5 (#10616), tested in test/disk-health.test.ts ("a PERC virtual disk is behind a controller, never an SSD"). Already done on main in cf39091f5; nothing left to split.

Already done on main in cf39091f5: the last box (parseSmartJson with named refusals and behind-controller for a PERC disk) landed with #10616 and is tested in test/disk-health.test.ts.

already done on main: cf39091f5

Deferred behind the Later gate: the last box shipped in cf39091f5 (#10616) and is tested in test/disk-health.test.ts. #10465 no longer waits on this issue. The forge refused both drop and done, so a person can close this.