Update ADR docs to reflect profile message system (#569)

ADR 005 rewritten to document the current architecture: profiles
stored as ProfileUpdate/ProfileSnapshot XMTP messages instead of
appData. Covers message-primary reads with appData gap-fill,
snapshot triggers, typed metadata, JoinRequest content type,
MemberKind enum, encrypted avatar references, and migration phases.

Cross-references updated in ADRs 001-004, 007, 009 to reflect that
profiles no longer share the 8KB appData space.

Author: yewreeka

docs/adr/001-invite-system-architecture.md

@@ -177,7 +177,7 @@ Key design decisions:
 ### Negative
 
 - **Complexity:** Cryptographic operations and multi-stage encoding add implementation complexity
-- **8KB Metadata Limit:** XMTP appData field constrains amount of metadata (tags, profiles, expiration)
+- **8KB Metadata Limit:** XMTP appData field constrains amount of metadata (tags, expiration). Profiles were moved to dedicated XMTP messages (see ADR 005), freeing significant appData space.
 - **No Centralized Analytics:** Can't track invite usage without backend
 - **Revocation Lag:** Updating invite tag only affects future joins, can't force-expire already-shared invites
 
@@ -225,7 +225,7 @@ While the creator's inbox ID is visible in invites, this is not a privacy concer
 - ADR 002: Per-Conversation Identity Model (explains the per-conversation inbox architecture used for invite creators)
 - ADR 003: Inbox Lifecycle Management (explains how pre-created inboxes optimize the join flow)
 - ADR 004: Conversation Explode Feature (join error feedback follows the same custom content type codec pattern)
-- ADR 005: Profile Storage in Conversation Metadata (also uses XMTP custom metadata, shares the 8KB appData limit)
+- ADR 005: Member Profile System (profiles moved to XMTP messages; appData no longer shared with profiles)
 
 ## References
 

docs/adr/002-per-conversation-identity-model.md

@@ -236,7 +236,7 @@ This ensures complete data removal when a conversation is deleted.
 **Related ADRs:**
 - ADR 003: Inbox Lifecycle Management (for pre-creation cache, LRU eviction, sleep/wake patterns)
 - ADR 004: Explode Feature (explains how destroying an inbox destroys the conversation's cryptographic identity)
-- ADR 005: Profile Storage in Conversation Metadata (explains how per-conversation identities enable per-conversation profiles)
+- ADR 005: Member Profile System (per-conversation identities enable per-conversation profiles via ProfileUpdate messages)
 
 ## References
 

docs/adr/003-inbox-lifecycle-management.md

@@ -414,7 +414,7 @@ After eviction completes, we double-check state before proceeding since another
 **Related ADRs:**
 - ADR 002: Per-Conversation Identity Model (explains why lifecycle management is needed)
 - ADR 004: Explode Feature (uses inbox deletion process for conversation explosions)
-- ADR 005: Profile Storage in Conversation Metadata (per-conversation profiles rely on per-conversation identities)
+- ADR 005: Member Profile System (per-conversation profiles rely on per-conversation identities)
 
 ## References
 

docs/adr/004-explode-feature.md

@@ -328,7 +328,7 @@ However, the per-conversation identity model provides cryptographic assurance: e
 
 - ADR 002: Per-Conversation Identity Model (explains why destroying the inbox destroys the conversation's cryptographic identity)
 - ADR 003: Inbox Lifecycle Management (explains inbox deletion process)
-- ADR 005: Profile Storage in Conversation Metadata (also uses XMTP custom metadata for expiration timestamps)
+- ADR 005: Member Profile System (profiles use XMTP messages; expiration timestamps remain in appData)
 
 ## References