Remove E.164 validation for optional phone fields

[AutumnQiu99]

Summary

• Removes strict E.164 check from optional_phone() in backend/validators.py.
• Prevents unnecessary 422 responses for optional phone input.
• Preserves existing normalization behavior (trim + empty => None).

Test plan

• Submit request with phone omitted → succeeds
• Submit request with phone: "" / whitespace → treated as None, succeeds
• Submit request with non-E.164 phone (e.g. "4125551234") → no 422 from validator
• Submit request with E.164 phone (e.g. "+14125551234") → still succeeds

Closes #120

[gekiclaws]

Good fix for allowing Optix phone data to save. Since Optix gives us phone as a naive string, I agree we shouldn’t reject the whole user payload just because it isn’t E.164.

The remaining issue is that phone is currently doing double duty as both raw profile data and an SMS-sendable destination. We should allow optional_phone() to store the raw trimmed string, but SMS preference/send logic should only consider the phone valid if it is actually sendable, likely E.164 for now.

Concretely, I think optional_phone() can stay permissive, but normalize_effective_notification_state() should distinguish hasPhone from hasSmsPhone, or at least require E.164 before allowing "text" in notifPrefs. Otherwise a naive Optix value like "4125551234" can be saved and may let SMS notifications get enabled, only to fail later when Twilio receives it.

[AutumnQiu99]

Added hasSmsPhone field, whose value is determined by is_e164_phone