plan_call phone-number validation is inconsistent and mislabels malformed numbers as region errors

[Sarcastic-Soul]

Summary

calle call plan inconsistently validates phone-number format, and when it does flag a malformed number, the clarifying question mislabels it as a region-support problem rather than a formatting problem.

Environment

@call-e/cli@0.5.0, calle auth login completed, region US, language English.

Reproduction

Ran calle call plan --to-phone <num> --goal "Test plan only, do not run: confirm business hours" --region US --language English three times, varying only the phone number:

to-phone	Result
+15551234567 (555 exchange — NANP-reserved fictional range)	plan_id=p7GZ6G5EM. Rejected with clarifying question: "Calls to this region are not supported right now."
+14155550123 (valid NANP-format fictional number)	Accepted cleanly — only asked to confirm execution intent (expected, since the goal literally says "do not run").
+1234567890 (invalid area code 123 — arguably worse-formed than the 555 case)	Accepted with zero validation complaint — treated identically to a fully valid number.

Problem

The 555-exchange number is malformed/fictional, not tied to an unsupported region — US is obviously a supported region and the other two examples in the same region are accepted. But the clarifying question tells the user "calls to this region are not supported right now," pointing them at the wrong fix. Meanwhile a differently-malformed number (bad area code) passes with no validation at all, so the check isn't consistently applied either.

This looks like the same root class of problem described in #180 (call_not_ready overloaded across unrelated conditions) and #88 (E.164 validation inconsistent across surfaces), but at a different layer: the plan_call clarifying-question flow itself, before any call is created or a call-level error code is even involved.

Expected behavior

• Phone-number-format problems should be flagged consistently (both malformed examples above should behave the same way), and
• when flagged, the clarifying question/error should name the actual problem (malformed/fictional number) rather than "region not supported."

Impact

An integration or end user acting on the clarifying question here would try switching region/language rather than fixing the phone number — the literal wrong remediation path.