docs(next): document the NEXT_LOCALE override in headersAndCookies

[moss-bryophyta]

What

The headersAndCookies reference in the Next.js config page says every field "defaults to the library's standard name." Since gt-next@11.1.3 (generaltranslation/gt#2004) that is incomplete: withGTConfig repoints localeCookieName at NEXT_LOCALE whenever the Next.js config sets i18n and leaves localeDetection enabled, so Pages Router locale persistence matches the cookie the router actually reads.

The part worth calling out

The override is applied after props.headersAndCookies in the merge:

const mergedHeadersAndCookies = {
  ...defaultWithGTConfigProps.headersAndCookies,
  ...props.headersAndCookies,
  ...(nextLocaleDetectionEnabled && {
    localeCookieName: nextLocaleCookieName,   // 'NEXT_LOCALE'
  }),
};

So it wins even when you set localeCookieName yourself. A reader configuring a custom cookie name currently has no way to tell from the docs that it is silently replaced. The callout documents that precedence and the localeDetection: false opt-out.

Verification

• Behavior confirmed by reading packages/next/src/config.ts and packages/next/src/utils/cookies.ts upstream, not inferred from the changelog.
• Callout type="info" matches the existing convention in this file.
• validate:callouts (431 files), validate:structure, validate:reference-links (385 files), and validate-links all pass.

Context

Follow-up to #426, where I flagged this gap rather than expanding that PR's scope. Independent of #426 — no file overlap, so the two can merge in either order.

[moss-bryophyta]

Superseded by #430, which landed the same guidance in react/(frameworks)/nextjs/config.mdx (the NEXT_LOCALE preference-cookie override plus the v11.1.3 localeDetection: false escape hatch). Nothing unique left here, so closing instead of rebasing a redundant conflict.