A strict langCode read 404s config entities in their own base language (the 404 advertises that same language)

Since #3613823 made langCode the only read selector, a strict-mode config entity request was gated on configEntityHasOverride(), which tests for an override language only. On an English-default site, GET /jsonapi/menu/menu/{uuid}?langCode=en therefore 404'd and GET

/jsonapi/menu/menu?langCode=en omitted every menu without a dedicated "en"

override, even though the entity's own base language content exists. A client that uniformly appends langCode could not read config entities in the site's own language at all.

The 404 also contradicted itself: it advertised "Available translations" via availableConfigLangcodes() (base language plus overrides), so the error listed the very langcode the strict check had just rejected.

Replace both call sites with the availableConfigLangcodes() base-plus-overrides definition already used correctly by the include/collection-item path and by translationNotFound()'s own advertised list. The individual-read guard fails open when the language manager is not a ConfigurableLanguageManagerInterface, matching how the access checker degrades on a non-multilingual site. Fallback mode is untouched: it already serves base values when the requested language has no override. Remove the now-unused configEntityHasOverride() helper.

Add coverage for the base-language contract on menus (individual and collection), for a strict miss whose 404 advertises only the languages the entity really has, and for the previously untested config include path via a node's node_type relationship, in strict and fallback mode.

Co-Authored-By: Claude Fable 5 noreply@anthropic.com

Closes #3614382