Define conservative cooldown behavior during sensor faults

[danielbrownjr]

Follow-up from PR #1 interlock review. This is important safety-policy work, but it is not a Phase-0 merge blocker.

Problem

Current blocked() cooldown behavior only commands fan output when sensors_ok() is true, and sensors_ok() requires all required temperature sensors to be valid and finite.

That means a single failed sensor can suppress cooldown fan output even when another valid sensor still reports residual heat.

Example:

• chamber sensor: open/invalid
• outlet sensor: valid and hot
• case sensor: valid and hot
• heater: correctly blocked
• current fan policy: 0% because the aggregate sensor-valid condition fails

The safest behavior is not yet established. We should not casually invent a policy before considering airflow hardware, residual-heat behavior, reboot/brownout handling, and fault recovery.

Decision required

Define the product-level cooldown/fault policy for:

• one sensor invalid while another valid sensor indicates residual heat;
• all temperature sensors unavailable or implausible;
• sensor failure while actively heating;
• normal stop versus latched fault;
• reboot/brownout during cooldown;
• fan failure during required cooldown;
• minimum/maximum cooldown duration if temperature evidence is unavailable;
• recovery and fault-clear prerequisites.

Acceptance criteria

• Conservative cooldown behavior is explicitly documented.
• The policy distinguishes trustworthy remaining temperature evidence from complete sensor uncertainty.
• Interlock/fan behavior is updated if required.
• Host tests cover the chosen fault-state transitions.
• Bench/HIL tests demonstrate cooldown behavior on release-intent hardware.
• The safety verification record identifies retained evidence and its location.

Related: PR #1.

[danielbrownjr]

Phase-0 model update from PR #1 corrective safety review (commit 8459894): blocked/fault cooling now stops only when every required sensor is valid, finite, and at or below the cooldown release threshold. Any partial or complete temperature uncertainty requests 100% fan output, and any remaining valid hot sensor remains actionable; a valid sensor can independently latch its sensor-specific overtemperature trip even when another sensor has failed. Host tests cover each invalid status, NaN/Inf, partial invalid+hot evidence, complete uncertainty, and fully valid/cool release. Physical fan behavior, reboot/brownout policy, and release-intent HIL/bench validation remain outstanding, so this issue stays open.