docs(README): sync locale lists with the code for isAlpha, isAlphanumeric, isFloat and isIBAN

[simonkundrik]

The locale lists in the README have drifted from the code. 32 locales that the validators genuinely support aren't listed anywhere in the docs, so there's no way to discover them short of reading the source.

Docs only, no behaviour change.

Validator	Documented before	In code	Added
isAlpha	70	76	az-AZ, bn-BD, fa, fa-AF, vi-VN
isAlphanumeric	70	76	az-AZ, bn-BD, fa, fa-AF, vi-VN
isFloat	49	68	bn-BD, bn-IN, el-GR, fa-AF, fa-IR, gu-IN, hi-IN, id-ID, kk-KZ, kn-IN, ku-IQ, ml-IN, or-IN, pa-IN, si-LK, ta-IN, te-IN, vi-VN
isIBAN	78	80	DZ, MA

How I found it

Diffed each README row against the exported locale list (validator.isAlphaLocales, isAlphanumericLocales, isFloatLocales, ibanLocales) rather than eyeballing it. The same check now passes in both directions for all four.

Worth noting the reverse direction is clean: the README never documents a locale that doesn't exist, so there was no case of a documented locale throwing at runtime. This is purely under-documentation.

Verified, not assumed

Every added locale was confirmed to actually work:

validator.isAlpha('Salam', 'az-AZ');            // true
validator.isAlpha('xin', 'vi-VN');              // true
validator.isAlpha('سلام', 'fa');                 // true
validator.isAlpha('ঢাকা', 'bn-BD');              // true
validator.isFloat('1,5', { locale: 'vi-VN' });  // true
validator.isIBAN('DZ580002100001113000000570'); // true

Existing entries were already in sorted order, so the new ones are inserted alphabetically and each row keeps its own separator style (', ' for the alpha/float rows, ',' for the IBAN row). The diff is 4 lines.

One deliberate omission

pl-Pl exists in alpha, alphanumeric and decimal as a back-compat alias for pl-PL (src/lib/alpha.js, "see #862"). I left it undocumented since it's a legacy casing variant rather than a real locale, and documenting it would invite new code to use the odd casing. Happy to add it if you'd rather the lists mirror the keys exactly.

This is related to #1266 but doesn't close it — that thread moved on to the broader ISO 639-1 vs ISO 3166-1 standardisation question, which this doesn't touch.

Full suite 290 passing, eslint clean.

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable) — docs-only change, no test surface
• References provided in PR (where applicable)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (d4e02ee) to head (e60a9c1).

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #2840   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          114       114           
  Lines         2598      2598           
  Branches       658       658           
=========================================
  Hits          2598      2598           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.