Fix/rma bugfixes

[orilupo]

1. Le RMA da form guest vengono collegate all'account cliente (a41ae1c)

Quando un guest invia una richiesta RMA per un ordine che in realtà appartiene a un cliente registrato, la RMA viene ora associata a quell'account.

In precedenza il controller passava sempre null come customer ID, quindi queste RMA non comparivano mai nell'area riservata del cliente.

2. Localizzazione delle label lookup: email, resolver e form (ef7438c)

Le label di status, reason, resolution e condition non venivano tradotte né nelle email transazionali né nelle select del frontend.

Email e resolver:
Service\Email\Sender ora avvia la store emulation (area frontend) prima di risolvere le variabili del template, così __() usa il locale dello store view invece di quello admin.

Le variabili extra vengono costruite in modo lazy tramite closure, in modo che la risoluzione delle label avvenga dentro il contesto emulato; l'emulation viene sempre chiusa nel blocco finally, anche in caso di eccezione.

Form option source:
AbstractLookupSource::toOptionArray() ora avvolge la label di default dal DB con __(), propagando il fix a tutte le select (reason, resolution type, item condition), sia customer che guest, Luma e Hyvä.

Gli override store-specific inseriti dagli admin restano volutamente intatti: sono già nella lingua di destinazione.

Aggiunte le traduzioni delle label seed ai CSV i18n: de_DE, es_ES, fr_FR, it_IT, ro_RO.

3. TypeError in getList() dei repository (bf5449d)

Il TypeError si manifestava in ogni percorso che invoca getList() dei repository del modulo: comandi CLI (mageos:rma:list, mageos:rma:cleanup), resolver GraphQL, endpoint REST, caricamento di item/commenti e risoluzione degli stati.

Tutti gli otto repository dichiaravano return type specifici per entità (StatusSearchResultsInterface, ecc.), mentre la DI risolveva la classe non tipizzata Magento\Framework\Api\SearchResults, causando un TypeError a ogni chiamata di getList().

Ogni interfaccia ha ora una classe concreta dedicata in Model/Data/, collegata tramite preference in etc/di.xml.

Inizialmente avevo valutato una singola classe concreta che implementasse tutte e otto le interfacce SearchResults (meno boilerplate), ma ho scelto una classe per interfaccia: le preference DI restano auto-documentanti, si rispetta l'Interface Segregation Principle e ogni getItems() può dichiarare nel docblock il tipo corretto per IDE e analisi statica.

[SamueleMartini]

@orilupo puoi aggiornare il file CHANGELOG? Suggerirei la versione 2.4.0 visto che associare il reso all'account se viene fatto da form guest è un'aggiunta.
Così poi pubblico, grazie!