When downloading translations the plugin doesn't take any custom locales into account

OneSky allows you to set a custom locale for a language:

When downloading translation files from the OneSky website it respects this custom locale, but the plugin currently uses the original locale.

It appears that the [fetch project languages API](https://github.com/onesky/api-documentation-platform/blob/master/resources/project.md#languages---list-languages-of-a-project) has an undocumented `custom_code` attribute that is returned for languages.

Sample response from one of our projects:
```json
{
"code": "lv-LV",
"custom_locale": "lv",
"english_name": "Latvian (Latvia)",
"is_base_language": false,
"is_ready_to_publish": false,
"last_updated_at": "2024-03-28T20:38:38+0000",
"last_updated_at_timestamp": 1711658318,
"local_name": "Latviešu (Latvija)",
"locale": "lv",
"region": "LV",
"translation_progress": "100.0%"
},
{
"code": "te-IN",
"custom_locale": null,
"english_name": "Telugu (India)",
"is_base_language": false,
"is_ready_to_publish": false,
"last_updated_at": "2023-12-29T22:22:27+0000",
"last_updated_at_timestamp": 1703888547,
"local_name": "తెలుగు (భారత దేశం)",
"locale": "te",
"region": "IN",
"translation_progress": "59.4%"
},
```

It would be nice if the plugin respected the custom_locale when downloading a translation.

Start by locating the code that calls the OneSky project-languages API and selects locales for translation downloads. Check how the response's custom_locale value is represented and used, including the null case. Done means downloads use custom_locale when present and the original locale otherwise; add or update coverage if the repository has tests for this path.

Written by the indexing model from the issue text.