v0.4.1 — the update guard now sees a gate started by systemd

A safety fix for the one-click updater introduced in v0.4.0. If you are on 0.4.0, take this one;
everything else in v0.4.0 (real FM demodulation, S-meter, SDRplay support, the Pi image) is
unchanged and described there.

What was wrong

The updater is supposed to refuse to install while a gate is running — swapping the code under a
live radio session is exactly the surprise the feature exists to avoid. It only checked for a gate
that the setup page itself had started.

On an appliance the gate normally runs as a systemd service (aether-gate-9700.service and
friends), which the page did not start. So the check never fired, and an update could install
underneath a gate that was streaming to AetherSDR at the time.

Found by running the update for real on a Pi 4 rather than trusting the tests — every unit test
passed throughout, because they only ever exercised the path the page knew about.

What changed

The check now looks for any running gate, and says which one to stop:

A gate is running as a system service. Stop it before updating
(sudo systemctl stop aether-gate-*), then try again.

rather than "press Stop", which is useless advice for a service the operator never started from
that page.

Verified on the appliance: with a gate running as a service the install is refused (HTTP 409), and
the full path — Stop, Install, Start — then completes in about two seconds and leaves a working
gate with the previous version kept alongside.

---

Full changelog: v0.4.0...v0.4.1