Run the Pot simulation from server startup, not just once a Sud loads

PotTask.on_process() only calls Pot.process() once Pot.is_configured()
- which required plant params (M/C/L/Td) that, by design, only ever
came from a Sud's own doc via SudTask.apply_plant_params(). So with no
Sud loaded (or the temp controller disabled), the simulated Pot just
sat inert: manually driving the heater never moved its temperature at
all.

EMPTY_SUD's pot_mass/pot_material defaulted to 0/None, which would
have made a zero-mass plant (a ZeroDivisionError in Pot.process()) -
they're actually the physical kettle's own properties, not really
per-recipe (every sude/*.json so far uses the same pot), so default
them to that real kettle's values instead. server/brewpi.py now seeds
the Pot with derive_plant_params() from the not-yet-loaded Sud right
away, same as ambient temperature already was - a real Sud's own doc
still overrides these the moment one is loaded.

components/sud.py

@@ -59,8 +59,17 @@ def _build_step(number, defaults, raw_step):
 EMPTY_SUD = {
 	'Name': '',
 	'Description': '',
-	'pot_mass': 0,
-	'pot_material': None,
+	# pot_mass/pot_material are the physical kettle's own properties, not
+	# really per-recipe (every sude/*.json so far uses this exact pot) -
+	# defaulting to 0/None here used to make derive_plant_params() come out
+	# with a zero-mass plant (a ZeroDivisionError in Pot.process() waiting
+	# to happen) for as long as no Sud had ever been loaded yet. Matching
+	# the real kettle here instead lets server/brewpi.py seed the Pot with
+	# a physically sane default at startup, so its simulation actually
+	# runs - and a real Sud's own doc still overrides these the moment one
+	# is loaded (see SudTask.apply_plant_params()).
+	'pot_mass': 5.96,
+	'pot_material': "Edelstahl 18/10",
 	# Pot energy loss coefficient [W/(kg*K)] and transport propagation
 	# delay [s] - see derive_plant_params(). Defaults match the generic
 	# values brewpi.py used to hardcode for every brew alike.