docs: drop the last two "self-hosting deployments" phrases in SUB_PROCESSORS

Cleanup pass on yesterday's tone overhaul missed the Notes blocks of the
Sentry and Resend entries — both still framed AGPL forks as
"self-hosting deployments", which is the framing we agreed to drop
across customer-facing copy.  Reframed to match the section header
("If you fork and run your own copy") that was already updated.
Substance is unchanged — the legal point that an AGPL fork doesn't
engage *our* Sentry/Resend relationships still stands.

Author: Sbussiso

docs/legal/SUB_PROCESSORS.md

@@ -85,8 +85,9 @@ terminate the affected Service per Section 4.4 of the
 - **Privacy policy:** https://sentry.io/privacy/
 - **DPA reference:** https://sentry.io/legal/dpa/
 - **Notes:** Disabled when the `SENTRY_DSN` environment variable is
-  unset. Self-hosting deployments and any deployment that hasn't
-  configured a DSN do not engage Sentry as a sub-processor.
+  unset. SourceBox's own deployment runs with Sentry enabled; an
+  AGPL-3.0 fork running without a DSN does not engage Sentry as a
+  sub-processor for that deployment.
 
 ### Resend — *optional, off by default*
 - **Service provided:** Transactional email delivery for operator-
@@ -108,10 +109,10 @@ terminate the affected Service per Section 4.4 of the
 - **DPA reference:** https://resend.com/legal/dpa
 - **Notes:** Disabled when the `EMAIL_ENABLED` environment variable
   is unset or `false`. Resend is also bypassed when `RESEND_API_KEY`
-  is unset. Self-hosting deployments that haven't configured both
-  do not engage Resend as a sub-processor. Recipient emails are
-  derived from Clerk org membership at send time — no separate
-  mailing-list state is held by SourceBox or Resend.
+  is unset. An AGPL-3.0 fork that hasn't configured both does not
+  engage Resend as a sub-processor for that deployment. Recipient
+  emails are derived from Clerk org membership at send time — no
+  separate mailing-list state is held by SourceBox or Resend.
 
 ---