Integrate governed address contact resolution

docs/DISTRIBUTION_LISTS_ARCHITECTURE.md

@@ -83,6 +83,16 @@ The first capabilities should be:
 - `dist_lists.expand`: expand a distribution list into immutable recipient rows.
 - `dist_lists.writer`: explain whether a caller can create or change a list.
 
+When `addresses.contact_point_resolution` is available, address-contact and
+address-list entries are resolved through that versioned contract. Entry and
+expansion channel constraints are intersected, and purpose, effective time,
+address purpose, fallback rule, locale, and postal format are passed to the
+provider. Selected and rejected contact points retain stable reason codes and
+provider provenance. The frozen Distribution Lists snapshot stores the exact
+rendered target and contact-point ID, so later address changes do not rewrite
+delivery evidence. Legacy Addresses lookup/email-source capabilities are used
+only as a compatibility fallback.
+
 Consumers must resolve those capabilities through core and must not import
 distribution-list ORM or service internals.
 
@@ -98,9 +108,9 @@ Likely consumers:
 
 ## Relationship To Address Lists
 
-`govoplan-addresses` should implement classical address lists first. A
-distribution list may later include an address list as an entry, but the
-address module remains the owner of contact records and address-only grouping.
+`govoplan-addresses` implements classical address lists. A distribution list
+may include an address list as an entry, but the address module remains the
+owner of contact records and address-only grouping.
 
 The distribution-list module owns mixed operational routing. This prevents
 campaign-specific recipient logic from becoming the platform's de facto