[poplolioi11]

Fixes #676.

LocaleWrapper extracts fallback variants from the original tag, retaining their letter case, while range matching compares those variants using strict equality. As a result, changing oxendict to OXENDICT can change which available variant is selected under matching and lookup.

Lowercase only the extracted fallback variant. Native Intl.Locale construction and its input validation stay unchanged, and the public result still returns the original available-locale string (for example, en-US-OXENDICT). This follows the case-insensitive matching requirement in RFC 4647 section 2.

Added eight public-API regression/control cases: lowercase, uppercase available variant, uppercase requested variant, and an invalid non-ASCII variant, under both strategies.

Validation on Node 24.22.1:

• Original source with final tests: 4 failed, 17 passed in fluent-langneg/test/langneg_test.js.
• Patched full suite: 742 passed, 3 existing skipped, across 58 files.
• Workspace builds, lint, API documentation generation, and changed-file Prettier checks passed.
• Real headless Chromium 138.0.7204.23, without native Intl.Locale.prototype.variants: the four uppercase cases select the wrong variant before the patch and the expected variant afterward.
• Native-path controls in Chromium 151.0.7922.34, Firefox 153.0, and WebKit 26.5 already pass on the original source and remain unchanged after the patch. The affected scope is the fallback path; this does not claim a defect in those modern browser implementations or an affected deployed product.

AI assistance: Codex helped prepare the patch, tests and description; Gemini independently reviewed the final diff. All execution results above were verified locally.