Field formatters don't expose the parent entity's rendered langcode, so translation-aware reload plugins can't reconstruct the correct translation

Problem/Motivation

Both ViewsReferenceFieldFormatter::viewElements() and ViewsReferenceLazyFieldFormatter::viewElements() / ::lazyBuilder() build the $view->element['#viewsreference'] array with parent_entity_type, parent_entity_id, parent_field_name, parent_revision_id, and field_item_delta - but never the langcode of the translation that was actually rendered.

This is harmless for the normal render path, since the formatter already has the correctly-translated $items->getEntity() to read field settings from directly. But any consumer that needs to reconstruct this same context later - for example, an alternate compression service that reloads the parent entity from only these scalar values - has no way to know which translation the original render used, and falls back to the entity's default translation. On a multilingual entity whose Views Reference field settings differ per translation, this silently produces the wrong settings.

Steps to reproduce

1. Create a translatable entity (e.g. a paragraph) with a Views Reference field where an "enabled setting" differs per translation (e.g. a language-restriction filter on the referenced view).
2. Add a translation with a different value for that setting.
3. Render the non-default translation and inspect the #viewsreference element built by the field formatter - note it has no langcode.

Proposed resolution

Add parent_entity_langcode (the $langcode already passed into viewElements(), threaded through the lazy builder's args) to the #viewsreference array in both formatters, so consumers can call $entity->getTranslation($langcode) when reconstructing context.

API changes

None. A new key (parent_entity_langcode) is added to the #viewsreference array; existing keys are unchanged.