Enhance phone validation with country picker and richer error messages

[Skrypt]

Description

• Replace PhoneValidationResult with Result<PhoneEntry> from OrchardCore.Infrastructure in IPhoneFormatValidator.Validate(), keeping PhoneValidationResult marked [Obsolete] for backward compatibility
• Mark IsValid() as [Obsolete] with a default interface implementation that delegates to Validate(), so existing implementations remain compatible without changes
• Add XML API docs with a code example to IPhoneFormatValidator showing how to call Validate() and access E164Number, NationalNumber, RegionCode, and CountryCode; PhoneEntry also has full XML docs
• Implement rich validation in DefaultPhoneFormatValidator using libphonenumber-csharp, returning all previously available field values via PhoneEntry inside Result<PhoneEntry> with detailed localized error messages (invalid country code, too short, too long, etc.)
• Add intl-tel-input phone input component with country dropdown, flags, dial codes, as-you-type formatting, and inline validation icons
• Bundle as ES module via Vite with dark mode support and OrchardCore asset conventions
• Update UserPhoneNumber.Edit.cshtml and SmsAuthenticator/Index.cshtml to use the new component
• Normalize phone numbers to E.164 format on save in UserPhoneNumberDisplayDriver and SmsAuthenticatorController
• Remove DefaultPhoneRegion from LoginSettings entirely; use Thread.CurrentThread.CurrentUICulture as the server-side region fallback when no region code is submitted
• Phone editor country picker starts empty by default (no auto-IP detection, no server-side pre-selection from thread culture); users can optionally pick a region, and the server uses the thread culture region as a fallback
• Add .node-version file (24.14.1) to fix CI copilot job failure caused by the branch missing the file introduced in a recent main PR
• Add development/ to not_in_nav in mkdocs.yml so internal development plan docs under src/docs/development/ are excluded from the docs navigation without breaking the "Validating Building the Documentation" CI workflow

[Skrypt]

@copilot where should I put these development plans documentation so that it doesn't break the "Validating building the documentation" Github workflow?

[Copilot]

@copilot where should I put these development plans documentation so that it doesn't break the "Validating building the documentation" Github workflow?

Development plan docs should go in src/docs/development/ (e.g. src/docs/development/features/phone-validation/plan.md). I've added development/ to the not_in_nav section in mkdocs.yml (commit d483216) so any files under that directory are intentionally excluded from the docs navigation without triggering the strict-mode warning that breaks the CI workflow.

[sebastienros]

The Tel editor, should allow users to optionally pick a region. But by default it will be empty and then the phone editor will use the Thread region.

[Copilot]

The Tel editor, should allow users to optionally pick a region. But by default it will be empty and then the phone editor will use the Thread region.

Done in commit 07929cf — PhoneInput.cshtml no longer pre-computes a region from the thread culture, so data-phone-region is empty by default. The JS initializes intl-tel-input with initialCountry: '' instead of 'auto', meaning no country is pre-selected. When the user picks a country, intl-tel-input formats accordingly; when no region is submitted, the server falls back to Thread.CurrentThread.CurrentUICulture.

[Skrypt]

@copilot

We introduced this file in a recent PR I did. Why would it fail to find that file?

[Copilot]

@copilot

...

The .node-version file was added to main after our branch was created, so our branch didn't have it. Fixed in commit 34c43cc by adding .node-version (content: 24.14.1) matching what's in main.

[github-actions]

This pull request has merge conflicts. Please resolve those before requesting a review.

[hishamco]

Is it ready for review?

[github-actions]

This pull request has merge conflicts. Please resolve those before requesting a review.

[Skrypt]

This is a new module that could be moved to a different PR. I refactored the MonacoEditor integrations with a new MonacoEditor shape to show an example and also show the utility of the module. We have a lot of code in OC that could make use of a CommonShape module like this.

[sebastienros]

Content Type picker, Media manager, are these shapes or components (vuejs or viewcomponent). Should we follow the same pattern? I wonder if these should be shapes.

[Skrypt]

I need something shareable. Either shapes (server side) and / or common JS framework "Bloom". Need to think about it. But also, this would centralize components in one place instead of having them everywhere.