Drush Site Langcode Behavior / Always providing a site?

Enabling a module with drush can result in all configs being updated / their langcode changed.

Reproduce:

• The Site wide default langcode is "en"
• The Site with ID: 1 (I think it selects the first?), has the selected site langcode: "de"
• Enable a module with drush
• drush recognizes \Drupal::languageManager()->getDefaultLanguage()->getId() as de since it is overwritten by SitesLanguageOverrides::initiateContext function. This is because a site is provided even in drush CLI context. If that site has a different langcode than "en", all config gets updated with a new langcode, caused by LocaleConfigManager::updateDefaultConfigLangcodes.

Possible solutions:

a) We check in SitesLanguageOverrides::initiateContext if we are in a CLI Context

if (PHP_SAPI == "cli") {
  \Drupal::languageManager()->setDefaultLanguage('en');
  return;
}

I'm unsure if that should be hardcoded en or we should get the default language by \Drupal::service('language.default')->get()->getId(). The LocaleConfigManager::updateDefaultConfigLangcodes function, seems to hardcode en as well, which I'm not sure I understand why.

b) We do not provide a site in general for drush CLI Contexts. This seems to be contradictory to the comment in CurrentSiteContext::getActiveSite(), which says:

// Always provide a value here for the site context, so it will be
// available for mapping even in ajax requests where cannot determine the
// site properly.

Maybe this is where the issue stems from.

Personally I would prefer solution b) since it seems like the cleaner solution. But it might have implications when running drush cron and site context being needed for some crons?

Solution a) would be a simpler fix, but maybe not as clean.

I can provide a merge request once we decide on the solution.