feat(scheduling): use central people picker

README.md

@@ -82,10 +82,12 @@ uses Poll context fields to point back to its request or proposal resource.
 Typical workflow steps are collect availability, rank candidates, decide, notify
 participants, and hand off to Calendar or Appointments.
 
-The manifest declares `access` and `evaluation` as optional dependencies.
-Scheduling may use Access for identity, groups, and permissions, and may trigger
-post-event or post-appointment feedback through Evaluation. It must not require
-either module just to find a meeting time.
+The manifest declares `access`, `addresses`, and `evaluation` as optional
+dependencies. Scheduling uses Core's principal-aware people-search boundary to
+combine only the account and contact records visible to the current organizer;
+it never calls the instance-wide Identity search. It may trigger post-event or
+post-appointment feedback through Evaluation, and must not require any of these
+optional modules just to find a meeting time.
 
 ## Expected Integrations
 
@@ -98,6 +100,22 @@ either module just to find a meeting time.
 - `govoplan-portal`: external participant scheduling flows
 - `govoplan-workflow` and `govoplan-tasks`: follow-up work after a time is selected
 
+## Participant selection boundary
+
+The editor uses Core's shared `PeoplePicker`. Its server-side search aggregates
+the optional `access.people_search` and `addresses.people_search` capabilities,
+and each provider applies the active principal and tenant visibility rules
+before returning a candidate. Scheduling exposes only the fields needed to
+select a person; provider provenance, address-book topology, group membership,
+and other internals are not returned by its picker endpoint.
+
+An account selection becomes an internal participant bound to that account.
+A visible address-book contact becomes an external participant with a bounded
+directory-selection reference and revision for later organizer editing. Manual
+name-and-email entry is available only while the request allows external
+participants. The picker stores neither provider-internal provenance nor a
+global Identity record reference in participant metadata.
+
 ## First Package Scaffold Decision
 
 The first backend implementation slice adds runtime APIs and storage around