Fix regional language URL resolution for fallback content (CST-6191)

[MortenFriisSiteImprove]

Problem and change

Selecting a regional language for content inherited from another language can return a master-language URL or fail to load the page. The controller currently disables configured fallback and drops the editor's locale before URL resolution.

Honor configured fallback/replacement rules and pass the selected locale through to the URL resolver. Resolve the public page without its editor revision; calls without an editor locale use the page's language. For example, an en-US selection can retain its /en-us/ route even when the loaded content is English. Optimizely still supplies the route; no customer domains or language mappings are hardcoded.

Existing origin mappings remain in effect. The original helper method remains available, with a default implementation of the new overload for existing custom helpers. Such helpers need to implement the overload to gain locale-aware behavior.

Validation

• Before changing production code, 15 of the initial 16 regression cases failed on both .NET 6 and .NET 8; the missing-route control passed.
• All those cases pass after the fix. Added three further cases for missing locales and existing custom helper implementations.
• Full backend suite: 75 passed on each target, zero failures/skips.
• Existing browser suite: 20 passed across Chromium and Firefox.
• Locked dependencies and package target unchanged; existing .NET 6 support warning remains.

The new tests exercise the production controller and helper with content/URL resolution doubles. They do not establish actual CMS fallback routing or live Siteimprove report matching. See validation and risk assessment.