Fan demand scale is ONE global multiplier applied to four physically different fans

OPERATOR-RAISED 2026-09-10: “the fan demand scale needs to have a per fan value not a single value”. TODAY: scale_fan_demand_pct(pct) reads ONE fan_demand_scale from global modifiers and multiplies EVERY fan demand by it. Settings shows a single slider: “Multiplies every fan demand the brain sends. 1.0 is nameplate.” WHY IT IS WRONG: there are four physically distinct fans — fan.dsc_hub_4_inch_intake_fan_main, fan.dsc_hub_4_inch_intake_fan_2x4, fan.dsc_hub_6_inch_exhaust_room, fan.dsc_hub_6_inch_exhaust_outside. Different sizes, different ducting, different static pressure, different nameplates. Trimming the 2×4 intake because it is loud also trims the room exhaust, which is not what the operator means. It also interacts badly with the tracked fan-curve coverage gap (only 1 of 4 curves is measured, the other three report nameplate) — a single fudge factor is being asked to stand in for four different calibrations. SHAPE OF THE FIX: 1. fan_demand_scale becomes a per-entity map (keep the scalar readable as a migration: an existing single value seeds all four, so nothing changes on upgrade). 2. scale_fan_demand_pct takes the fan entity id and looks up its own scale, falling back to 1.0. 3. Settings → Climate → Fans renders one row per fan with its label, not one global slider; the manifest row and settingsIndex keywords follow. 4. Every call site of scale_fan_demand_pct must pass the entity — grep first, because a caller that cannot name its fan is a caller applying the wrong scale. NOT a blocker for anything shipped; the current behaviour is coherent, just too coarse.