feat: auto-gate radiators on heat network surplus

Radiators and Thermal Canister Missile launchers pull from the same heat
pool with identical NetworkResourceOutput settings, and priorities.rules
defines no ordering for heat. A constantly-running radiator therefore
spends missile ammunition to make steam.

Gate radiator dissipation on three network signals instead of the raw
PowerToggle: a 98%/94% hysteresis band on the thermal battery, whether
any launcher is actually set to thermal ammo, and an override driven by
the engine's own OverflowHeatStorage as a safety net.

Storage fullness causes no damage on its own -- only overflow does, and
only above 350 status per tile -- so the band sits high deliberately to
keep the network full as a missile reserve.

Signal polarity is "hold", not "vent", so any ship missing a broadcaster
falls back to vanilla behaviour.

Includes an offline validation suite that resolves every patch target,
component reference and component Type against the installed game data,
since all three otherwise fail only as a crash on game load.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni

README.md

@@ -0,0 +1,140 @@
+# Auto Radiator
+
+A Cosmoteer mod. Radiators stop dumping heat the ship still wants.
+
+## The problem
+
+Thermal Canister Missiles are built from the ship's own heat. The game says so
+itself, in `Data/strings/en.rules`:
+
+> Manufactures guided Thermal Canister Missiles that take thermal energy from
+> their own ship's heat pipe network and inflict it upon the target.
+
+The launcher charges each missile from the heat network — `HEAT_PER_MISSILE =
+8500`, two missiles buffered per launcher. A radiator pulls from that same
+network, through a component that is behaviourally identical to the launcher's:
+
+| | Radiator | Thermal launcher |
+|---|---|---|
+| Type | `NetworkResourceOutput` | `NetworkResourceOutput` |
+| Mode | `DistributeProportionallyByAvailable` | `DistributeProportionallyByAvailable` |
+| Categories | `[ thermal_storage ]` | `[ thermal_storage ]` |
+
+`Data/ships/priorities.rules` defines priorities for crew and supply only —
+nothing for heat. So the two compete flat, proportionally, and a radiator
+running constantly is spending your ammunition to make steam.
+
+## Why holding heat is safe
+
+Heat storage being full does not hurt you. Damage comes only from *overflow*.
+Every overclocked part routes its heat through this
+(`Data/ships/base_part_overclock.rules`):
+
+```
+HeatDistributionStorage
+{
+	Type = MultiResourceStorage
+	ResourceStorages = [NetworkHeatInput, OverflowHeatStorage]
+	AddMode = InOrder
+}
+```
+
+`InOrder` means the network is tried first, and `OverflowHeatStorage` only
+receives what the network refuses. Overflow then applies the `cosmoteer.heat`
+status to the producing part's own tiles.
+
+From `Data/statuses/heat/heat.rules`, that status does nothing whatsoever below
+**350** per tile (`RequireValueRangeForTick = [350, Infinity]`). Fire chance
+ramps from 350 to 2500; thermal damage begins at 700.
+
+An overclocked large reactor produces 2750 heat/sec over its 4×4 footprint —
+about **172 status/sec per tile** while fully overflowing, so roughly **2
+seconds of continuous, total overflow** before fire risk even arms. Radiators
+react within **0.5 s** (`HeatDissipationConverter { Interval = 0.5 }`).
+
+At a 98% ceiling on a single 15000-capacity thermal battery, the overshoot
+during that reaction window is about 625 status heat spread over 16 tiles —
+roughly **39 per tile**, against a threshold of 350. Holding the network near
+full is safe with a wide margin, and every percent of ceiling given up is
+ammunition thrown away for nothing.
+
+The genuine constraint is not the threshold. It is total radiator throughput
+(1100/sec each) versus sustained generation. If you are short on radiators you
+overflow continuously and no threshold value saves you — which is what the
+safety net below is for.
+
+## What the mod does
+
+Radiators vent when **any** of these is true:
+
+1. The heat network is not asking them to hold — the thermal battery is at or
+   above 98% full (dropping the hold again at 94%, a deadband so radiators do
+   not chatter at the threshold).
+2. No launcher on the network is set to Thermal Canister Missiles. If you are
+   not spending heat as ammunition there is nothing to hoard, so radiators
+   behave exactly as in vanilla.
+3. **Safety net:** some part is actually overflowing heat right now. This reads
+   the engine's own `OverflowHeatStorage`, so it fires the moment the network
+   genuinely refuses heat — regardless of thresholds, pipe topology, or whether
+   your radiator capacity was ever sufficient. Latched for 3 seconds so a
+   stream of per-tick overflow events becomes one steady signal.
+
+Your manual radiator on/off switch still overrides all of it. The automation can
+only idle a radiator you have left switched on.
+
+Ships with no thermal battery have no broadcaster, so nothing changes for them.
+The signal polarity is deliberately "hold", not "vent", so that the absence of
+any part of this mod's machinery always falls back to vanilla behaviour.
+
+No stat or number is changed. Only *when* radiators run.
+
+## Layout
+
+```
+mod.rules                                  manifest + patch actions
+components/thermal_battery_vent.rules      decides when there is surplus
+components/launcher_ammo_signal.rules      reports thermal ammo in use
+components/overclock_overflow_signal.rules safety net, reports real overflow
+components/radiator_auto.rules             combines the signals into one gate
+tests/                                     offline validation suite
+install.sh                                 validate + copy into the Mods folder
+```
+
+## Install
+
+```sh
+./install.sh
+```
+
+Then enable **Auto Radiator** in the game's Mods menu. `./install.sh --uninstall`
+removes it. If the script cannot find your Mods folder, set `COSMOTEER_MODS_DIR`.
+
+## Tests
+
+```sh
+python3 tests/test_mod.py
+```
+
+Cosmoteer applies mod actions to vanilla data at load time, and a path that does
+not resolve, a component reference pointing at nothing, or a misspelled
+component `Type` all fail identically: the game crashes on startup and leaves a
+log file. The suite parses the installed game's `.rules` tree and checks all
+three offline. It also self-checks the parser against known vanilla facts first,
+so a broken parser fails loudly instead of passing everything.
+
+Set `COSMOTEER_DATA` to point at a different install.
+
+## Status
+
+Validated against game data version 0.30.4c. The logic is verified statically —
+every patch target, component reference and component type is checked against
+the shipped `.rules` files — but it has not yet been run in-game. Worth watching
+on the first run: whether `NetworkToggleReceiver` with `AllowUncategorized =
+false` reads *off* on a ship with no broadcaster, which is the assumption the
+vanilla-fallback behaviour rests on.
+
+## Possible additions
+
+- A per-radiator UI toggle for auto/manual, which needs a new `ChoiceID` wired
+  into `Data/gui/game/parts/part_toggles.rules`.
+- Making the 98% / 94% band configurable.