fix(t1000): allow the OS to reset the ThinkPad fan after an EC latch

[ExtraToast]

Observed behaviour

The EC on enschede-t1000-1 latched the primary fan to full duty at 23:29 on 2026-08-23 and held it there. Over the following 8.7 h the tachometer reported a near-constant 6382 rpm across ~1030 consecutive 30 s samples, against a steady ~2470 rpm for the preceding week.

No thermal cause was present. Every sensor was flat or falling at the moment of the ramp, and afterwards the machine ran cooler than at any point in the retention window:

Sensor	During the latch	Prior 7-day norm
CPU package	40-47 C	52-62 C
PCH (pch_cannonlake)	68 C	74-77 C
SENB / SEN8	68 / 54 C	71-73 / 60 C
Quadro T1000	38 C at 4.7 W, 300 MHz	idle
NVMe 0 / 1	42 / 38 C	48 / 43 C
load1	0.98 on 12 threads	-

pwm1 read 255 with pwm1_enable 2, so the EC was commanding 100% duty in its own automatic mode, at an rpm above the 4650 maximum observed across the prior 15 days. The secondary fan never moved from ~2175 rpm.

Ruled out along the way: the 18:50 reboot (the latch began 4.6 h later), a NixOS regression (#762 touched only enschede-gtx-960m-1), platform_profile (reads balanced), and any workload trigger (the journal for 23:20-23:45 holds only tailscaled route churn, dhcpcd, and an nmbd master-browser election). Two readings that look alarming are artefacts: a 30000/1466 rpm pair at 18:21 during the pre-boot EC reset, and a single 84 C NVMe sample at 06:00 surrounded by 38 C.

Root cause of the unrecoverability

thinkpad_acpi defaults fan_control to N. That makes /proc/acpi/ibm/fan and the hwmon pwm1 attributes reject every write with -EPERM, so there is no way to hand fan control back to the EC from the OS. EC fan state survives a warm reboot, which leaves dropping power to the machine as the only remedy - and this node also serves LAN DNS through the hostNetwork AdGuard pod.

Change

fan_control=1 via boot.extraModprobeConfig, which makes the level 7 then level auto reset reachable over SSH the next time the EC latches. Delivering it through modprobe.d rather than a kernel parameter also means a modprobe -r thinkpad_acpi && modprobe thinkpad_acpi picks it up without a reboot.

The inline comment records the caveat that matters operationally: only level auto should ever be written back, because a manual level holds until something re-arms the EC.

Validation

• cd platform/tests && npm ci && node --test - 58 passing, 0 failing.
• Hardware context confirmed on the host: ThinkPad P1 Gen 2 (20QUS00000), BIOS N2OET55W 1.42, EC N2OHT35W, no battery present (only AC and two USB-C source PSYs in /sys/class/power_supply/).

This does not clear the current latch; a power cycle does. It makes the failure remotely recoverable from the next occurrence onward.