feat: normalize phone numbers to E.164 format before storage

[NOVA-Openclaw]

Problem

The memory extraction pipeline stores phone numbers in whatever format they appear in conversation (e.g. +1 817-896-4104, (512) 925-3157). Downstream consumers like the semantic-recall hook's entity resolver do exact-match lookups against entity_facts using E.164 format (+18178964104), which fails when the stored value has spaces, dashes, or parentheses.

Impact

This caused entity resolution to silently fail for all Signal messages — the hook could not match the sender's E.164 phone to the formatted phone in entity_facts, so entity profile context (timezone, preferences, communication style) was never injected.

Proposed Solution

In the memory extraction pipeline, normalize all phone numbers to E.164 format before inserting into entity_facts:

1. Strip all non-digit characters except leading +
2. Ensure country code is present (default to +1 for 10-digit US numbers)
3. Validate length (E.164 max 15 digits)
4. Store the normalized value

Example

Input	Normalized
+1 817-896-4104	+18178964104
(512) 925-3157	+15129253157
817.896.4104	+18178964104
+44 20 7946 0958	+442079460958

Scope

• Apply to all entity_facts with key = 'phone' or key = 'owner_number'
• Consider a one-time migration to normalize existing phone entries
• The extraction pipeline should normalize at insert time going forward

Context

• Fixed manually in production by adding a duplicate E.164 entry (entity_id=2)
• Related: semantic-recall hook uses entity-resolver from nova-relationships which does exact ef.value = $1 matching
• See also: .pgpass password was also stale (separate fix, same debugging session)