Add change spec: email-based conversation matching

Replace thread-ID-based conversation matching with email-address-based
matching for more reliable conversation continuity. Key changes:

- One conversation per email address (simpler model)
- No data expiration (conversations persist indefinitely)
- Post-completion support (questions and registration updates)
- Versioned storage for registration updates (audit trail)
- Admin notifications for registration changes

This addresses the gap where parents sending new emails (instead of
replying) would lose their registration progress.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

openspec/changes/email-based-conversation-matching/specs/registration-data-store/spec.md

@@ -0,0 +1,52 @@
+## MODIFIED Requirements
+
+### Requirement: Conversations keyed by email address
+The system SHALL store conversations using the sender's normalized email address as the unique key, replacing thread-ID-based storage.
+
+#### Scenario: Conversation file naming
+- **WHEN** storing a conversation for `parent@example.com`
+- **THEN** the system SHALL use a filename derived from the email address (e.g., `parent_at_example.com.json`)
+
+#### Scenario: Conversation lookup
+- **WHEN** loading a conversation for an incoming email
+- **THEN** the system SHALL lookup by normalized sender email address
+
+### Requirement: Registration updates stored as versions
+The system SHALL store registration updates as separate versions, preserving the original and all subsequent changes for audit purposes.
+
+#### Scenario: Initial registration stored
+- **WHEN** a registration is completed for the first time
+- **THEN** the system SHALL store it as version 1 with timestamp
+
+#### Scenario: Registration update creates new version
+- **WHEN** a parent requests changes to a completed registration
+- **THEN** the system SHALL store the updated data as a new version
+- **AND** the system SHALL preserve all previous versions
+
+#### Scenario: Version metadata
+- **WHEN** storing a registration version
+- **THEN** the version SHALL include: version number, timestamp, and change summary (which fields changed)
+
+### Requirement: Current registration accessible
+The system SHALL provide easy access to the current (latest) registration data while preserving version history.
+
+#### Scenario: Retrieve current registration
+- **WHEN** the admin or system requests the current registration for an email address
+- **THEN** the system SHALL return the most recent version
+
+#### Scenario: Retrieve version history
+- **WHEN** the admin requests registration history for an email address
+- **THEN** the system SHALL return all versions in chronological order
+
+## ADDED Requirements
+
+### Requirement: Post-completion conversation state
+The system SHALL support a "completed" conversation state that allows continued interaction for questions and updates.
+
+#### Scenario: Conversation continues after completion
+- **WHEN** a parent sends an email after their registration is complete
+- **THEN** the system SHALL load the existing conversation and process the message
+
+#### Scenario: Intent detection for post-completion messages
+- **WHEN** processing a message in a completed conversation
+- **THEN** the system SHALL detect intent: question, update request, or new child registration