Harden vapi_call_start destination phone parsing + restaurant lookup matching

[ByteStreams-AI]

Problem

During voice-path recovery we reproduced a brittle failure mode behind "Couldn't get assistant": if destination phone extraction or formatting drifts (payload schema variant, 10-digit vs +1 E.164 formatting), call-start can fail to resolve the restaurant and return a hard failure.

Why this matters

• This is a high-impact entrypoint failure: caller hears immediate failure instead of reaching the assistant.
• The failure is avoidable with tolerant parsing + normalization.
• We already have a local patch validated by ci:fast.

Proposed fix

1. In vapi_call_start, broaden destination phone extraction to accept both nested .number and direct string forms across message/call/root variants.
2. In shared context lookup, normalize destination + stored restaurant phone values (US 10-digit/11-digit and E.164-ish) before matching.
3. Keep behavior unchanged for valid existing payloads; this is strictly hardening.

Acceptance criteria

• Assistant-request succeeds when destination appears as either phoneNumber.number or phoneNumber string.
• Restaurant lookup resolves despite common US formatting differences (+1XXXXXXXXXX, 1XXXXXXXXXX, XXXXXXXXXX, punctuation).
• Existing tests remain green (pnpm ci:fast).
• No tenant-scoping or auth behavior changes.

Notes

• Worktree currently contains unstaged patch implementing this hardening and passing tests.
• Intended to land as a dedicated follow-up commit/PR after current docs/governance commit.

[ByteStreams-AI]

Follow-up note from PR #46 review: now normalizes phone formats and matches in-memory across active restaurants. This is the right immediate hardening, but we should add a duplicate normalized-phone guard so ambiguous matches fail loudly instead of first-match wins.\n\nProposed follow-up:\n- enforce uniqueness for normalized restaurant phone numbers (migration or index strategy), or\n- detect duplicates at runtime and return/log a deterministic error.\n\nThis is non-blocking for #46; tracking here for next hardening pass.

[ByteStreams-AI]

Correction to previous comment (formatting): In lookupRestaurantByDestination, phone formats are now normalized and matched in-memory across active restaurants. This immediate hardening is good, but we should add a duplicate normalized-phone guard so ambiguous matches fail loudly instead of first-match wins.

Proposed follow-up:

• enforce uniqueness for normalized restaurant phone numbers (migration or index strategy), or
• detect duplicates at runtime and return/log a deterministic error.

This is non-blocking for PR #46; tracking here for next hardening pass.