Validate and normalize host locale values

[lukewilliamboswell]

Context

The public Locale type is documented as a pragmatically validated BCP 47 language tag in platform/Locale.roc:3-6.

However, host values bypass Locale.parse:

• Locale.get! wraps the returned string directly at platform/Locale.roc:93-97
• Locale.all! does the same at platform/Locale.roc:99-104

The host can return values such as C or POSIX, which do not satisfy the module's own language-subtag validation. A local run currently returned C.

There is also an unreachable documented error: Locale.get! promises NotAvailable, but locale_get_string always substitutes en-US when discovery fails and hosted_locale_get always returns Ok:

• src/lib.rs:1764-1772
• src/lib.rs:1806-1810

Suggested direction

Define normalization rules for common OS locale forms, including:

• C and POSIX;
• underscore-separated forms such as en_US;
• encoding/modifier suffixes such as .UTF-8 and @variant.

Then validate every host-provided value before constructing Locale. If no valid locale can be derived, return NotAvailable rather than inventing a locale, unless the fallback is explicitly part of the documented contract.

Acceptance criteria

• Every value returned from Locale.get! and Locale.all! satisfies the same invariant as Locale.parse.
• C, POSIX, underscore forms, encoding suffixes, and malformed host strings have documented outcomes.
• NotAvailable is reachable when appropriate, or it is removed from the API.
• Duplicate normalized locales are handled intentionally.
• Cross-platform tests cover representative Linux, macOS, and Windows inputs independently of the machine's real locale.