Problem

src/locale/locales.json carries 47 locale entries but stores them as a flat A–Z map keyed by the English display name (Afrikaans, Arabic - Egypt, …). Every UI that renders a locale list — the admin debug page's Locale tab, the System Settings locale picker, User profile language dropdown, etc. — inherits this flatness:

• A non-English-speaking admin can't recognize their language. An admin in Brazil has to know that Portuguese maps to pt_BR and appears alphabetically under P — they never see Português do Brasil.
• No natural grouping. All English-variants (en_AU, en_CA, en_GB, en_JM, en_US, en_ZA) and all Arabic-variants scatter through the list.
• No signal of which locale is currently active.

Proposed schema additions

Add two fields to each entry in locales.json:

Existing fields (`isRTL`, `fullCalendar`, `momentLocale`, `dataTables`, `datePicker`, `poEditor`, …) stay untouched.

```diff
"Portuguese - Brazil": {
"poEditor": "pt-BR",
"locale": "pt_BR",
"languageCode": "pt",
"countryCode": "BR",

• "nativeName": "Português do Brasil",
• "region": "Americas",
  "dataTables": "pt-BR",
  …
  }
  ```

UX changes that unlock

Debug page Locale tab (`src/admin/views/debug.php`)

• Group rows under a `

  ` per region, each header showing `N installed / M total on server`.

• Language cell stacks `nativeName` over `languageName` (with locale code as small muted text).
• Badge `Active` on the row matching `SystemConfig::getValue('sLanguage')` so admins instantly see their own locale.
• Search input at the top that filters by any of: nativeName, languageName, locale code, region.

Other consumers (follow-up PRs, not this issue)

• System Settings `sLanguage` picker → region-grouped `` with native names.
• User profile locale picker → same.
• Verify/registration email locale selection → use `nativeName` where shown to recipients.
• Public directory (if/when i18n-exposed) → same data.

Implementation sketch

One PR delivers everything on the debug page side:

1. `src/locale/locales.json` — add `nativeName` + `region` to all 47 entries.
2. `ChurchCRM\Service\AppIntegrityService::getLocaleSetupInfo()` — pass both new fields through.
3. Rewrite the Locale tab: grouped rendering, native names, active-locale badge, search box.

Purely additive — no existing caller needs to change. `isRTL` / feature-flag fields stay as-is.

Out of scope

• Swapping the `` widgets elsewhere in the app is a separate UI pass and not required by this issue. Sorting/weighting locales by translation completeness — separate concern tracked elsewhere. Why now The admin debug page was rewritten in chore(deps): bump the build-tools group across 1 directory with 2 updates #8725 (`fix/admin-debug-dashboard-ux` branch) and the Locale tab surfaces the problem clearly: scrolling 47 flat rows to confirm your OS has `pt_BR` installed is a bad experience and representative of the flatness everywhere else.