/related/ reads the relationship from the host's default translation, ignoring langCode

Core JSON:API upcasts the route's entity through EntityRepository::getTranslationFromContext() before a controller runs. This module's forked EntityUuidConverter deliberately drops that upcast in favor of its own request-driven language selection, and getIndividual() compensates by re-resolving the host's translation. getRelated() never did: it read the relationship field off whatever the param converter produced, which is always the default translation.

On a site where a translatable entity reference field's translations point at different targets, a strict langCode request to /related/ silently returned the default translation's targets instead of the requested translation's. The same relationship read through ?include=field_x&langCode=... on the individual endpoint returned the correct, requested-language targets, so the two endpoints disagreed on the same data.

getRelated() now resolves the host's translation before reading the field: the requested translation when the host has it, the fallback chain when fallback mode is requested and it does not, and today's behaviour (default translation) otherwise. The fallback walk's cacheability is threaded onto the response so cached bodies vary correctly by access outcome, matching getIndividual().

Adds testRelatedReadsTheSelectedTranslation(), a characterization test with reference targets that exist in both languages so a pass can only be explained by the host-translation fix, not by the existing per-target language filtering.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

Closes #3614409