Fix "Attempt to reinitialise Reticulum" on setup/retry

RNS.Reticulum.__init__ sets its internal singleton before it can fail partway
through init, which left our module-level _RNS_INSTANCE cache out of sync (None)
while RNS believed it was already running. Every setup retry then hit RNS's
reinit guard and raised "Attempt to reinitialise Reticulum, when it was already
running".

Use RNS.Reticulum.get_instance() as the source of truth and adopt an existing
instance instead of re-creating it (with an OSError fallback that also adopts).
Also cache and reuse the LXMF router, delivery destination, identity and
announce handler across reloads so a reload never spawns a duplicate router or
stacks announce handlers.

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

README.md

@@ -207,9 +207,11 @@ action:
 
 - Reticulum uses a **single process-wide instance**. Only one Reticulum config
   entry is allowed, and because RNS/LXMF cannot be cleanly torn down inside a
-  running process, changing the host/port or fully restarting the stack requires
-  restarting Home Assistant. Option changes that don't touch the stack apply on
-  reload.
+  running process, the running stack is reused across reloads. Changing the
+  host/port (or recovering from a failed first start) therefore requires a
+  **full Home Assistant restart**, not just an integration reload — a reload
+  reuses the already-running stack. Option changes that don't touch the stack
+  apply on reload.
 - The identity is stored in `config/reticulum/identity` — back it up to keep the
   same address.
 - Assist replies use the standard conversation pipeline, so whichever agent you