MistDemo web: add phone-number support to /users/discover

[leogdion]

Context

PR #396 wired the user-identity routes into the MistDemo web app. During review we removed the two Apple-deprecated lookup routes (/users/lookup/email, /users/lookup/id) from the web surface and routed all lookups through the supported POST /users/discover endpoint instead.

/users/discover currently forwards emails and user record names (both via UserIdentityLookupInfo). The underlying discoverUserIdentities(lookupInfos:) also accepts phone numbers (UserIdentityLookupInfo(phoneNumber:)), but the web demo doesn't expose them yet.

Task

Add phone-number support to the demo's discover panel:

• Request DTO (WebRequests.DiscoverUsers): add a phoneNumbers: [String] field (decode with decodeIfPresent(...) ?? [], mirroring emails/userRecordNames).
• WebBackend.webDiscoverUsers + CloudKitService conformance (CloudKitService+WebBackend+Users.swift): accept phoneNumbers and append phoneNumbers.map { UserIdentityLookupInfo(phoneNumber: $0) } to the combined lookup-info array.
• Frontend (index.html + js/users.js): add a phone-numbers input to the Discover section; include phoneNumbers in the POST body and the CloudKit JS parity loop (discoverUserIdentityWithPhoneNumber).
• Tests/mock: extend DiscoverUsersCall + usersDiscoverForwards to cover phone numbers.

References

• PR Wire landed MistKit endpoints into MistDemo web app (#394) #396 (review follow-up)
• Examples/MistDemo/Sources/MistDemoKit/Server/WebServer+Users.swift
• Sources/MistKit/Models/Users/UserIdentityLookupInfo.swift

[leogdion]

Verification caveat for #425

The implementation follows this issue's spec exactly, and no Sources/MistKit/ change was needed — UserIdentityLookupInfo already had phoneNumber and a phoneNumber: init parameter, so the change is confined to Examples/MistDemo.

One caveat worth recording: the phone-number path was verified only through the mock backend, not against live CloudKit. DiscoverUsersCall + usersDiscoverForwards confirm that phoneNumbers is decoded from the request body and forwarded into discoverUserIdentities(lookupInfos:) as UserIdentityLookupInfo(phoneNumber:) — that is, the plumbing is proven, but not that CloudKit accepts these values or what format it expects.

Phone numbers are the likeliest of the three lookup kinds to have server-side format requirements (E.164 vs. national formatting, punctuation handling). If POST /users/discover is strict about that, the demo will forward whatever the user types and surface an opaque server error. Nothing in this change normalizes or validates the input.

Not proposing a fix — normalization may well belong to the caller rather than the demo — but flagging it so a live test with a real, discoverable phone number happens before this is treated as a working demo path.

🤖 Generated with Claude Code