Flag "revision_translation_affected" is not always set correctly

Problem/Motivation

Flag "revision_translation_affected" is not always set correctly.

Steps to reproduce

1. Create a content moderation setup with three states: archived (status = 0), draft (status = 0), and published (status = 1).
2. Enable content moderation using these three states.
3. Create an entity with the moderation state set to draft.
4. Use the content moderation info block to archive the entity.
5. Observe that the “revision_translation_affected” flag is not set, even though this change is related to the given revision.

Content moderation states are managed as separate entities, and transitioning from draft to archived does not involve changes to the fields on the entity itself (status stays 0). However, this state change is directly tied to the revision. As a result, the revision is not flagged as affected and may, for example, not appear in the Revisions tab.

Proposed resolution

Make sure, that entity used in content_moderation_info block is set correctly. And if it's set, don't override it. In current implementation the problem is when state field on content_moderation_info_block has any AJAX calls assigned. How drupal works, is that on first AJAX call on the page it calls:

getFrom
buildFrom
retrieveForm -> calls buildForm(), which uses entity from context + adds necessary things, like revision_translation_affected.
processForm
rebuildFrom
retrieveForm -> calls buildForm() which overrided prepared entity with entity from context. As result, e.g. revision_translation_affected is not set. That’s why I added if (!$this->getEntity()) { in buildForm() to prevent overriding entity set on first call of retrieveForm

Second and next calls without page reload are fine, because stack is:

getForm
buildForm
processForm
rebuildForm
retrieveForm -> calls buildForm() uses cached, prepared version of entity with revision_translation_affected correctly set.