Suppress signal handlers for the whole init (LXMF.LXMRouter too)

v1.0.2 only neutralised signal.signal around RNS.Reticulum(), but
LXMF.LXMRouter.__init__ also calls signal.signal(SIGINT/SIGTERM) (LXMRouter.py
308-309), so init still crashed with "signal only works in main thread of the
main interpreter" when the router was constructed in the executor thread.

Wrap the entire _start init (both constructors) with signal.signal neutralised
instead of just the RNS constructor. Confirmed via upstream source that the
only relevant signal registration sites are RNS/Reticulum.py:366-367 and
LXMF/LXMRouter.py:308-309, both module-attribute calls, so the module-level
patch intercepts both.

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

README.md

@@ -214,11 +214,12 @@ action:
   apply on reload.
 - The identity is stored in `config/reticulum/identity` — back it up to keep the
   same address.
-- RNS is a standalone-daemon-style library. To embed it cleanly the integration
-  suppresses RNS's own signal handlers (so Home Assistant keeps ownership of
-  SIGINT/SIGTERM — important under Kubernetes) and unregisters its blocking
-  `atexit` persistence, persisting RNS/LXMF state itself, off the event loop,
-  on the `homeassistant_stop` event. RNS still spawns a couple of non-daemon
+- RNS and LXMF are standalone-daemon-style libraries — both install
+  SIGINT/SIGTERM handlers and `atexit` persistence in their constructors. To
+  embed them cleanly the integration suppresses those signal handlers during
+  init (so Home Assistant keeps ownership of SIGINT/SIGTERM — important under
+  Kubernetes) and unregisters their blocking `atexit` persistence, persisting
+  RNS/LXMF state itself, off the event loop, on the `homeassistant_stop` event. RNS still spawns a couple of non-daemon
   worker threads, so on shutdown you may see a "non-daemonic threads" notice and
   a short delay before the process exits (within the pod's termination grace
   period).