docs(troubleshooting): suppression and bounces (engagement Phase 9)

ENGAGEMENT.md §6.0b assigns this repo the operator-facing half of Phase 9
(website#176 + docs#191). Two new sections, split along the line that actually
matters when somebody reports it.

"One person stopped receiving email" is the suppression case, and the three
things an operator gets wrong about it: they can still reset their password
(suppression scopes to engagement rules only, so that is the expected shape of
the problem rather than a contradiction); Not sent, Bounced and Failed in the
Send Log mean three different things and only one of them is about your
configuration; and no row at all means they were excluded before anything was
queued, by an opt-in or by the verification gate.

"Everyone stopped receiving email at once" exists to stop the wrong reflex. A
whole-deployment stop is never the suppression list — a wrong password never
suppresses anybody, only the receiving server naming a specific dead mailbox
does — and it says so before an operator starts clearing rows.

Also notes that lifting a suppression asks for the full address because
addresses are stored one way, so it reads as the privacy design rather than a
missing feature.

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

src/content/docs/docs/administration/troubleshooting.mdx

@@ -114,6 +114,38 @@ a Team. See [Teams](/docs/administration/teams/).
 - **A missed announcement does not come back.** Nothing retries; the post itself is still
   on the site.
 
+## One person stopped receiving email
+
+Everyone else is getting mail, so the transport is fine. Check
+**Engagement → Suppressions**, then **Engagement → Send Log**.
+
+- **They are on the suppression list.** The site stops mailing an address once the
+  receiving server says the mailbox does not exist. Addresses are stored one way and
+  shown masked (`d***@example.com`), so search by their domain to find the row. If they
+  have since fixed their mailbox, press **Lift a suppression** and type the full
+  address — the screen genuinely does not have it, which is why you are asked.
+- **Suppression only affects engagement rules.** Password resets, invites and address
+  verification still go out to a suppressed address, because those are things the person
+  asked for themselves. So "they can reset their password but get no notifications" is
+  the expected shape of this problem, not a contradiction.
+- **The Send Log says *Not sent*.** That is a suppression: nothing was sent to the mail
+  server at all. *Bounced* means it was sent and the mailbox does not exist. *Failed*
+  means the relay refused it for some other reason — that one is about your
+  configuration, not about them.
+- **The Send Log has no row for them at all.** They were excluded before anything was
+  queued. Either they have not opted in on **Notifications** for that stream, or
+  *Require a verified email address* is on in **Settings** and they have not confirmed
+  theirs. The rule editor's audience preview shows how many people each of those removes.
+
+## Everyone stopped receiving email at once
+
+Do **not** start clearing the suppression list — it is almost certainly not the cause.
+A whole-deployment stop is a transport problem: an expired password, a relay that has
+started refusing you, or *Enable email sending* switched off. The Send Log will show
+*Failed* rather than *Bounced* or *Not sent*, and **Settings → Email delivery** shows the
+last error. A wrong password never suppresses anybody; only the receiving server saying a
+specific mailbox does not exist does that.
+
 ## Uploads and modules fail with permission errors
 
 Docker created a bind-mount source that the container user cannot write — usually because