Add FQDN-change-specific causes to the push-notification troubleshooting doc

DNS propagation lag, TLS cert readiness, and a stale SiteURL all follow
directly from a migration that also changes domains, on top of the
DB-import device-registration cause already documented.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AddPmva5bfrUW3MoPriq21

services/mattermost.md

@@ -79,3 +79,30 @@ carrier blocking something, a half-finished Caddy/DNS cutover for the new
 VPS), that user can receive the push notification itself but never see
 real content, or see it inconsistently. Temporarily switching to "Send full
 message contents" removes this variable while narrowing down the cause.
+
+### 5. A changed FQDN specifically — DNS propagation and cert readiness
+
+If the migration also moved the server to a new domain (not just a new box
+under the same domain), that alone can produce exactly this
+some-users-fine/some-users-not pattern for a few days after cutover, on top
+of section 2 and 4 above:
+
+- **DNS propagation lags per device.** Different users' resolvers (ISP DNS,
+  carrier DNS on cellular, cached records with old TTLs) pick up the new
+  FQDN's IP at different times. A user on a fast public resolver sees it
+  immediately; someone on carrier DNS with a stale cache might not resolve
+  it correctly for hours. Combined with section 4 (anything but "full
+  message contents" requires a content-fetch call back to `SiteURL`), a
+  device with a stale answer for the new FQDN fails that step while others
+  succeed.
+- **TLS certificate not fully issued/propagated yet** for the new FQDN
+  (Caddy/Let's Encrypt) causes the same content-fetch failure via cert
+  validation instead of DNS.
+- **Confirm `MM_SERVICESETTINGS_SITEURL` in `.env` is actually the new FQDN**
+  — a value left over from before the domain change points every client's
+  content-fetch at the wrong place, consistently, not just intermittently.
+- Users who never explicitly added the new server URL in the mobile app (a
+  kept redirect from the old domain let them keep working without
+  noticing) are still running on their old, stale device registration —
+  this is section 2's mechanism, just caused directly by the FQDN change
+  rather than by the DB import alone.