User docs name the scanning engine and describe internal hops

Deferred from the ClamAV work on #184 (`codingjoe-turbo-spoon`).

lazyJoe defer lines:

```
defer: delete the rspamd name-drops in docs/docs/sending.md:L84,L132 and docs/docs/webhooks.md:L53. Same user-docs rule; files untouched by this change. [docs/docs/sending.md, docs/docs/webhooks.md]
defer: delete docs/docs/reliability.md:L93-119 (health endpoints, nameserver probe; ~15 lines). Dev-only text on a user page, untouched by this change. [docs/docs/reliability.md]
```

## What

The pages at `/docs/` mix customer-facing text with internals:

1. **Engine name-drops.** `rspamd` appears as a mermaid participant (`sending.md:84`, `deliverability.md:61`, `receiving.md:34`), as a node label (`security.md:98`, `reliability.md:20`), and in prose (`message-statuses.md:27,46,68,117`, `deliverability.md:101`, `receiving.md:66`, `webhooks.md:53`). A customer does not act on the engine name; "the scan" or "the scanner" carries the same meaning.
2. **Internal hops.** `receiving.md:46` and `deliverability.md:69` step through "the load balancer" in a sequence diagram. Nothing a customer does changes based on that hop.
3. **A whole dev-facing section.** `reliability.md:93-119` documents health endpoints and the nameserver probe. That is operational detail for whoever runs the deployment, not for a customer reading what relay guarantees.

The exception is `docs/docs/data-privacy.md:29`, which names `rspamd with ClamAV` on purpose: it is a subprocessor inventory, and transparency requires the real names there.

## Why it was deferred

All of it predates the ClamAV change. Touching 14 unrelated lines would have expanded a scanning PR into a docs rewrite, so it was left alone.

## Scope

Worth deciding first whether the engine name should appear anywhere outside `data-privacy.md`. If the answer is "no", this is a mechanical pass over the pages above plus a decision on `reliability.md:93-119`.

Read the listed pages under docs/docs/, especially sending.md, deliverability.md, receiving.md, security.md, message-statuses.md, webhooks.md, and reliability.md:93-119. First decide whether rspamd should remain only in data-privacy.md; done means customer pages omit unnecessary engine names and internal hops, while the reliability section is resolved consistently.

Written by the indexing model from the issue text.