Surface Sud's Load rejection as a server-driven error, not GUI guesswork

Sud.load() already refuses a new schedule while a run is in progress
(state not IDLE/DONE) - but tasks/sud.py's SudTask.recv() silently
dropped that refusal, and an earlier attempt to handle it client-side
by pre-emptively greying out the File menu based on the GUI's own
(replicated, laggy) view of sud_state was reverted: the intelligence
belongs on the server, which already knows definitively whether it's
running, not on the client guessing from a mirrored state that can
lag or miss the message that changed it.

tasks/sud.py: when Sud.load() returns False, send {'Sud': {'Error':
...}} explaining why, instead of doing nothing.

client/brewpi_gui.py: New/Save/Load Sud stay enabled unconditionally;
on_sud_changed() shows whatever 'Error' the server sends via
QMessageBox.warning(). on_action_sud_new()'s comment updated to match
(it goes through the same Load path, so gets the same rejection/error
for free).

Verified live: triggering Load while a run is in progress on an
isolated test server round-trips the Error over the wire and pops the
expected dialog ("Cannot load a new schedule while a run is in
progress - stop it first.").

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LhiQe64F74uHV8jzuoSa5K

tasks/sud.py

@@ -196,6 +196,13 @@ class SudTask(ATask):
 					await self.send({'Name': self.sud.name, 'Description': self.sud.description})
 					await self.send({'Json': pair[1]})
 					await self.send_forecast(pair[1])
+				else:
+					# Sud.load() refuses while a run is in progress (state
+					# not IDLE/DONE) - tell the client why instead of
+					# silently dropping the request. The client has no
+					# business pre-emptively guessing this itself from its
+					# own (replicated, laggy) view of the state.
+					await self.send({'Error': 'Cannot load a new schedule while a run is in progress - stop it first.'})
 
 	async def send(self, data):
 		await self.msg_handler.send(data)