v0.4.3 — the update guard no longer trips over its own search

A third fix for the one-click updater, found the same way as the other two: by running it on real
hardware rather than trusting the tests.

What was wrong

The "refuse to update while a gate is running" check searched the process list for aether_gate —
but pgrep -af aether_gate returns anything that mentions the name: the shell running the
search, an editor with the file open, a tail on the log. So the guard fired with no gate running
at all, refusing updates that should have been allowed.

That is the opposite of the v0.4.1 escape (which permitted updates it should have refused) and just
as useless: one lets an update run under a live radio, the other blocks updating forever.

It now requires an actual -m aether_gate module launch, and ignores -m aether_gate.setup (the
web UI itself) and any other submodule.

Also in 0.4.x

• v0.4.2 — the update banner clears as soon as the install finishes, instead of continuing to
  offer an update that was already applied
• v0.4.1 — the guard sees a gate started by systemd, not only one started from the page
• v0.4.0 — real FM demodulation, S-meter, SDRplay support, the Pi appliance image, and
  one-click updating itself

All three updater bugs were invisible to the unit tests, which only exercised the paths the code
already knew about. Each now has a regression test that fails when the fix is removed.

---

Full changelog: v0.4.2...v0.4.3