chore: Update PayPal locales

[shopware-octo-sts-app]

Automated update of supported PayPal locales list.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4f07871090

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "Codex (@codex) review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "Codex (@codex) address that feedback".

[chatgpt-codex-connector]

Keep regional fallback locales at index zero

When the shop locale has an unsupported language but a known region, such as en_ZA, LocaleCodeProvider::findMatchingSupportedLocale() reads SupportedLocales::LOCALES[$region][0]. This update rekeys every region's first locale from 0 to 1, so that lookup now returns null and getFormattedLocaleCode() incorrectly switches to the global en_GB default instead of the region's preferred PayPal locale (for ZA, en_US). Preserve zero-based keys or update the fallback lookup to select the first value.

Useful? React with 👍 / 👎.

[Max Stegmeyer (mstegmeyer)]

Closing — this PR contains no actual locale change.

All 202 regions, their order and their locale lists are byte-for-byte identical to trunk. The only difference is that the array keys shifted from 0-based to 1-based, because the scraper copied PayPal's "Language support priority" column verbatim into the keys and PayPal renumbered that column.

That shift would have broken LocaleCodeProvider::findMatchingSupportedLocale(), which falls back to SupportedLocales::LOCALES[$regionCode][0] — with 1-based keys that lookup misses for every region, so en_ZA, de_AT, fr_CA and friends would have silently fallen back to en_GB instead of the region's preferred locale.

Fixed in #760: the priority is now only used for sorting and the key is the resulting position, so upstream renumbering can no longer leak into the generated class. Running the fixed scraper against the live page reproduces trunk's SupportedLocales.php exactly, which is why there is nothing to merge here.