fix(i18n): use correct defaultLocale when domains array is present on default host

[hammadxcm]

What?

Fixes the defaultLocale resolution in RouteModule.prepare() when a domains array is configured in the i18n config and the request is served from the default domain (not a configured domain hostname).

Why?

When visiting a locale path like /fr on the default domain (e.g., localhost), detectDomainLocale() matches a configured domain entry (e.g., example.fr) based on the detected locale — not hostname. The matched domain's defaultLocale was then incorrectly used as the request's defaultLocale, causing:

• Wrong defaultLocale in getServerSideProps / getStaticProps args
• Wrong router.defaultLocale on SSR (sent via __NEXT_DATA__)
• Hydration errors from <Link> components rendering domain-prefixed hrefs

This is a regression introduced between v15.3 and v15.4 when the Pages Router handler was refactored to use RouteModule.prepare().

How?

Removed domainLocale?.defaultLocale from the defaultLocale fallback chain in RouteModule.prepare(). The correct defaultLocale is already set in request metadata by base-server.ts using hostname-only domain matching, so the locale-matched domainLocale value is not needed here.

The domainLocale variable (with locale-based matching) is still used for isLocaleDomain — which is needed for domain-prefixed link generation.

Before:

const defaultLocale =
  getRequestMeta(req, 'defaultLocale') ||
  domainLocale?.defaultLocale ||
  i18n?.defaultLocale

After:

const defaultLocale =
  getRequestMeta(req, 'defaultLocale') || i18n?.defaultLocale

Test plan

• Added regression test: visits /go/another and /do/another on localhost (no host header) and verifies defaultLocale is en-US (main config) in both GSSP props and router.defaultLocale
• Full i18n integration test suite passes (189/193, 4 skipped)
• Existing domain locale tests still pass (link domain prefixing, correct default locale on configured domains)

Fixes #90131