docs: document the systemd deployment and its graceful-shutdown behavior

deploy/install.sh and deploy/brewpi.service existed but were never
mentioned in the README - the only documented deployment path was the
older virtualenvwrapper-based server/brewpi.sh. Also ties in the
SIGTERM handling fix, since systemctl stop is exactly the path it
protects.

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

README.md

@@ -266,6 +266,25 @@ pip install -r client/requirements.txt
 `server/brewpi.sh` shows how this is wired up to run under a `virtualenvwrapper`
 environment (`$WORKON_HOME`/`$BREWPI_HOME`) on a Raspberry Pi-style deployment.
 
+### Running as a systemd service
+
+`deploy/install.sh` installs `deploy/brewpi.service` as a systemd unit
+(`BREWPI_HOME` is derived from the script's own location, substituted into
+the unit via `envsubst`):
+
+```bash
+./deploy/install.sh
+sudo systemctl start brewpi
+journalctl -u brewpi -f
+```
+
+`systemctl stop`/`restart` send `SIGTERM`, which `server/brewpi.py` routes
+through the same shutdown path as Ctrl-C (`SIGINT`/`KeyboardInterrupt`) -
+so a service stop still cancels all tasks, forces the heater to 0 W and the
+stirrer to a stopped state (`AHeater`/`AStirrer.activate(False)`, via each
+task's `with device.open():`), and flushes the server/sud logs before the
+process exits, rather than being killed mid-state.
+
 ## Mash schedules
 
 Files under `sude/` describe a brew's mash schedule ("Sud"): `pot_mass`,