Python to 3.13.14

[dpy013]

  ### Link to issue number:
  None
  ### Summary of the issue:
  Python 3.13.14 completely rewrote the `windows_locale` mapping table in `Lib/locale.py` to align with the [MS-LCID specification (revision 16.0)](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-lcid/70feba9f-294e-491e-b6eb-56532684c37f). This introduced new LCID entries for Central Kurdish (`0x0092: "ku"`, `0x7c92: "ku"`, `0x0492: "ku_IQ"`).

In Python 3.13.13, these entries did not exist, so ckb was classified as an unsupported Windows language and the locale assertion in test_NVDASupportedLanguages_LanguageIsSetCorrectly was skipped. In Python 3.13.14, ckb is now recognized by Windows (LCID 0x0492), but Windows maps it to ku_IQ (language code ku) rather than ckb, causing the test assertion 'ckb' != 'ku' to fail.
### Description of user facing changes:
None. This is an internal Python version bump and test fix with no user-facing behavior changes.
### Description of developer facing changes:
- The pinned CPython version is now 3.13.14 across all build configurations, CI workflows, and developer documentation.

• A new WINDOWS_LOCALE_ALIASES mapping is introduced in tests/unit/test_languageHandler.py to handle cases where Windows returns a different but related language code than the one NVDA uses. Future locale mismatches can be resolved by adding entries to this dictionary.
  ### Description of development approach:
  1. Updated Python version from 3.13.13 to 3.13.14 in:
• .python-versions (root, x86_64)
• runtime-builders/synthDriverHost32/.python-version (x86)
• .github/workflows/autofix.yml
• .github/workflows/fetch-crowdin-translations.yml
• .github/workflows/testAndPublish.yml (defaultPythonVersion and supportedPythonVersions)
• projectDocs/dev/createDevEnvironment.md

2. Fixed the ckb locale test failure by adding a WINDOWS_LOCALE_ALIASES dictionary in tests/unit/test_languageHandler.py that maps ckb → ku, and updated the thread locale assertion to use WINDOWS_LOCALE_ALIASES.get(langOnly, langOnly) instead of langOnly.
   References:

• Python 3.13.14 Lib/locale.py

• Python 3.13.13 Lib/locale.py

• MS-LCID specification

• Python 3.13.14 release notes
  ### Testing strategy:
  - CI run on dpy013/nvda branch py3.13.14: all jobs pass after the fix (Build, unit tests, Pyright type check, license check, translator comments, symbols).

• The WINDOWS_LOCALE_ALIASES mapping is designed to be extensible — if similar locale mismatches surface on different Windows versions, new entries can be added without modifying test logic.
  ### Known issues with pull request:
  None.
  ### Code Review Checklist:

  - [ ] Documentation:
    - Change log entry
    - User Documentation
    - Developer / Technical Documentation
    - Context sensitive help for GUI changes
  - [ ] Testing:
    - Unit tests
    - System (end to end) tests
    - Manual testing
  - [ ] UX of all users considered:
    - Speech
    - Braille
    - Low Vision
    - Different web browsers
    - Localization in other languages / culture than English
  - [ ] API is compatible with existing add-ons.
  - [ ] Security precautions taken.
  

action run:
https://github.com/dpy013/nvda/actions/runs/29052432147

[seanbudd]

I don't think this is the correct fix.
windows_locale is being removed in Python 3.13 as per python/cpython#144738

Instead we need to remove using windows_locale and use winKernel.LCIDToLocaleName instead. This involves changing languageHandler.windowsLCIDToLocaleName, removing _LCIDS_TO_TRANSLATED_LOCALES_OVERRIDES

def windowsLCIDToLocaleName(lcid: int) -> str | None:
	"""
	Gets a normalized locale from a Windows LCID.

	NVDA should avoid relying on LCIDs in future, as they have been deprecated by MS:
	https://docs.microsoft.com/en-us/globalization/locale/locale-names
	"""

	localeName = LCIDS_TO_TRANSLATED_LOCALES.get(lcid)
	if not localeName:
		localeName = winKernel.LCIDToLocaleName(lcid)
	if localeName:
		return normalizeLanguage(localeName)