docs(portal): declare DSAR ownership boundary

docs/SERVICE_DIRECTORY_CONCEPT.md

@@ -149,3 +149,26 @@ must not infer missing milestones or expose values, people, evidence, internal
 notes, or handoff details. A reload action re-fetches the authoritative
 projection. Missing, disabled, revoked, expired, or unauthorized grants share
 a non-enumerating unavailable state.
+
+## Data-subject request ownership
+
+Portal has no module-owned persistence and therefore does not contribute a
+`privacy.dsar.portal` provider. Its routes resolve and render bounded
+provider-owned projections during each request; they do not copy service
+definitions, launch parameters or results, Postbox entries, status grants,
+submission values, email addresses, or applicant identities into Portal.
+
+Data-subject request coverage follows the authoritative owner:
+
+- Services covers configuration-author attribution for versioned service
+  definitions;
+- Cases, Forms Runtime, and Workflow Engine cover launch effects and domain
+  instances;
+- Postbox covers mailbox records; and
+- Forms Runtime covers status-access grants, token lifecycle, confirmations,
+  acknowledgements, and submitted Form data.
+
+Authentication state, request/security logs, and infrastructure telemetry are
+Core or deployment-operator concerns, not Portal records. If Portal later gains
+durable personalization, analytics, saved searches, contact data, or session
+persistence, that change must add a tenant-scoped DSAR provider before release.