fix: keep absorbed names for the post-merge report, relabel the orphan check

[dhongu]

Două defecte de raportare, găsite rulând scripturile pe baza de staging a unui client.
Ambele sunt în verificarea de după unificare — logica de merge propriu-zisă nu se schimbă.

1. Secțiunea E nu putea afișa denumirile absorbite

Masterul e ales după volumul de documente, nu după calitatea denumirii, așa că uneori
supraviețuiește fișa cu numele lipit la import. Secțiunea E le listează, ca să fie corectate
manual — și le arăta alături de denumirile de pe fișele absorbite, ca alternativă.

Doar că le citea printr-un JOIN pe acele fișe, care la momentul verificării sunt deja șterse.
Coloana ieșea mereu goală, exact în cazurile unde era utilă:

   id   |     denumire_master      | motiv                         | variante_absorbite
 727929 | MayaVirágKft             | cuvinte lipite (import prost) |
 776675 | OTPFaktoringZrtCsoportaz | cuvinte lipite (import prost) |

Denumirile se capturează acum în pm_snapshot la pasul 02, înainte de merge, și se citesc
de acolo.

2. Secțiunea D era etichetată înșelător

D numără orfanii polimorfi din toată baza, inclusiv pe cei lăsați de ștergeri anterioare
făcute din interfață sau din alte scripturi. Titlul însă se citea ca și cum ar raporta
rezultatul lotului curent.

Pe staging a afișat 835 de rânduri orfane în mail_message — niciunul produs de unificare.
Cifra lotului e verificarea de la finalul lui 03, care filtrează pe pm_map și a dat zero pe
toate cele cinci categorii. Titlul și comentariul spun acum explicit ce măsoară și ce nu.

Context: rularea care le-a scos la iveală

Lot de 50 de grupuri, aplicat pe staging:

Verificare	Rezultat
Fișe absorbite rămase	0
Abateri facturi / comenzi / livrări / sold	0 din 50 de masteri
Referințe rămase către fișele absorbite (03)	0 pe toate cele 5 categorii
Progres	6.050 → 6.000 grupuri de duplicate

Zero abateri înseamnă că fiecare document și fiecare leu de sold nereconciliat de pe fișele
absorbite a ajuns pe master.