Add a Gitea deploy workflow and the systemd unit it restarts

Shaped after the Livetrail workflow: one job on a project-labelled host
runner, preflight checks, rsync from the runner's checkout. rsync rather
than a pull in the live directory, so the deploy needs no credentials of
its own for git:.

The tests run first and gate the rest, .venv and members.json are excluded
so the runtime and the learned stereo pair survive, and the last step
waits for the panel to answer -- the home page renders from config alone,
so it says the app came back up without waiting on the speakers.

The unit carries the real paths and user, which the README's sketch of it
never did.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -84,26 +84,41 @@ if you ever put it behind a domain name, give it HTTPS.
 
 ## Run it as a service
 
-```ini
-# /etc/systemd/system/heos-panel.service
-[Unit]
-Description=HEOS panel
-After=network-online.target
-
-[Service]
-ExecStart=/home/pi/heos/.venv/bin/python /home/pi/heos/app.py
-WorkingDirectory=/home/pi/heos
-Restart=always
-User=pi
-
-[Install]
-WantedBy=multi-user.target
-```
+`deploy/heos-panel.service` runs the panel out of its own virtualenv and
+restarts it if it dies:
 
 ```bash
+sudo cp deploy/heos-panel.service /etc/systemd/system/
+sudo systemctl daemon-reload
 sudo systemctl enable --now heos-panel
 ```
 
+Edit `User=` and the paths in it if you keep the panel somewhere else.
+
+## Deploying from Gitea
+
+`.gitea/workflows/deploy.yml` runs the tests on every push to `main`, then
+rsyncs the tree into place, installs anything new from `requirements.txt`,
+restarts the service and waits for the panel to answer again.
+
+It needs a runner **in host mode on the machine that serves the panel**,
+registered with the label `heos` (`runs-on:` must match, or the job queues
+forever), running as the user that owns the directory. Restarting needs
+one sudoers line:
+
+```bash
+echo 'franzz ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart heos-panel' \
+  | sudo tee /etc/sudoers.d/heos-panel
+sudo chmod 440 /etc/sudoers.d/heos-panel
+```
+
+The rsync excludes `.venv` and `members.json`, so the runtime and the
+learned stereo-pair membership survive a deploy. It does *not* exclude
+`config.py`: your device names live in git, so commit changes to them
+rather than editing the deployed copy. And since the deploy path is also
+where you edit, `--delete` lands on top of anything uncommitted sitting
+there.
+
 ## Behind a reverse proxy, at /heos
 
 `deploy/heos.conf` reverse-proxies `/heos` to the panel with Apache: