This issue is related only to non-integral content fields - when there are some leftover content field translations (in ezcontentobject_attribute table) which does not exist anymore in the content / content version language masks. This causes next versions of this content contain invalid translations because language mask of the next content version is built based on all languages of the previous version fields instead of language mask of a previous content version.

The issue affects probably all Ibexa 3 and 4 versions.

Steps to reproduce:

1. Clean installation of Ibexa DXP.
2. Create new content in eng-GB and add one translation in pol-PL.
3. Dump single record from `ezcontentobject_attribute` table for any field in pol-PL language.
4. Remove pol-PL translation for this content using admin UI.
5. Reimport previously dumped single pol-PL field record.
6. Create new version in eng-GB language for this content using admin UI.
7. Observe the list of content translations.

Result:
New version of the content contains pol-PL translation even though we have removed it before.

Expected result:
New version of the content should contain only eng-GB translation.

Additional details:
We know that non-integral `ezcontentobject_attribute` table is not likely to happen in the newest Ibexa versions, but this issue can relate to older versions of eZ Platform / eZ Publish updated to Ibexa. Our main concern is that a language mask of a new content version is built based on fields translations instead of previous version's language mask, which should be the main control point for the version's languages.
This place where this happens is DoctrineDatabase content gateway class - `insertVersion()` method:

'language_mask' => $query->createPositionalParameter(
    $this->languageMaskGenerator->generateLanguageMaskForFields(
        $fields,
        $versionInfo->initialLanguageCode,
        $versionInfo->contentInfo->alwaysAvailable
    ),
    ParameterType::INTEGER
), 

This may be valid for a first version of a newly created content, but for existing content I think we should look at the language_mask of a previous version instead of creating a new one based on fields.{}

In my personal opinion, I think the above method is fine, but a good fix and overall improvement would be loading not all content field translations, but only those which matches content's language mask.