Per-fan ‘Fan demand scale’ sliders never command a fan: they only rescale the hub’s reported fan % before the brain computes CFM, so a moved slider silently ske

FIXED 2026-09-14 (PR #270, merged eb7d6a5, deployed 21:1x, bundle index-BbJnQM1A.js): option (a). The row copy was already honest since the morning; now the labels, the settings search index, the Climate route subline, the manifest row (label + description) and the journal lines all say “Fan airflow correction” — nothing left claims to multiply a demand. Commanding fans from the brain remains 58c8 (brain-owned demand mode). Verified on the Sensors/Climate settings walkthrough against the demo brain and by the live bundle. — ORIGINAL: Found 2026-09-14 while scoping the operator’s pressure-target feature. scale_fan_demand_pct has exactly one caller: the computed fast path reads each fan’s duty from the hub controls (fan_pct_from_controls), multiplies it by that fan’s demand scale, publishes the product as sensor.dsc_fan*_pct and feeds it into the CFM model. Nothing sends a scaled demand to a fan: in Full Auto the hub firmware computes OUT / RECIRC from temperature and RH and slaves the intakes to 70 % of exhaust, and the brain’s automation rules never offer fans. Yet the Settings rows read ‘Multiplies the demand the brain sends this fan. 1.0 is nameplate.’ and the manifest says ‘Multiplies every fan demand the brain sends’. Consequence: an operator who drags a slider expecting quieter or harder fans changes nothing physical, while every airflow number the brain shows (fan %, CFM, ACH, net pressure, mass balance) quietly moves by that factor. Fix options: (a) relabel it honestly as a per-fan CFM correction and stop publishing the scaled value as the fan’s duty; or (b) retire it in favour of the calibration curves. Either way the displayed fan % must be the duty the hub reports.