fix(m3-hermes): stable Matrix device + DNS pin for homeserver

Root cause chain of recurring Matrix outages (2026-08-16):

1. DNS on m3-hermes resolves exclusively via the Netbird-managed
   resolver. When the Netbird nameserver group is unreachable
   (observed 14:03-15:24), matrix.m3ta.dev fails to resolve.
2. A gateway restart during that window fails the Matrix login, and
   without MATRIX_ACCESS_TOKEN the gateway drops Matrix permanently
   from its reconnect queue ('no bot credential on queued config').
   Recovery happens only on the next restart - with working DNS.
3. The stable-token setup from 2026-08-14 was wiped because it was
   only written to the regenerated .env, not to the agenix secret.

Changes:
- Pin matrix.m3ta.dev to the m3-atlas public IP (TLS termination)
  so the Matrix connection survives Netbird DNS outages.
- Declare MATRIX_DEVICE_ID=HERMES01 in the module environment so the
  device id survives .env regeneration. The matching
  MATRIX_ACCESS_TOKEN must be added to secrets/hermes-env.age
  (separate manual step: agenix edit + re-encrypt).

hosts/m3-hermes/services/hermes-agent.nix

@@ -104,6 +104,15 @@ in {
       GIT_COMMITTER_EMAIL = "m3ta-chiron@agentmail.to";
       GIT_INIT_DEFAULT_BRANCH = "master";
 
+      # ── Matrix: stable device (Fix 0, root cause of ghost-device churn) ──
+      # Every gateway restart with password login creates a NEW device on the
+      # homeserver when MATRIX_DEVICE_ID is unset. The matching secret
+      # MATRIX_ACCESS_TOKEN lives in agenix (secrets/hermes-env.age). The token
+      # also keeps Matrix in the gateway's reconnect queue: without it, a
+      # failed startup (e.g. transient DNS outage) permanently drops the
+      # platform ("no bot credential on queued config").
+      MATRIX_DEVICE_ID = "HERMES01";
+
       # ── API Server (OpenAI-compatible, for Hermes Desktop App) ─────────
       # Accessible via Netbird mesh VPN — not exposed to the public internet.
       # Bind to 0.0.0.0 so the Netbird interface can reach it.