L'OLT n'a même pas envoyé son vendor ID, donc c'est ce qui est parfois appelé "fake O5".

Le PLOAM a bien été appliqué, si on suppose que l'ONT Bouygues le dérive bien de son IMEI (cad qu'il n'a pas été paramétré de manière différente pour la collecte axione/aquilenet).
Tu peux vérifier le SN appliqué avec "onu gtcsng", mais normalement la commande sfp_i2c devrait avoir fonctionné.

Je ne sais pas si l'OLT le vérifie, mais normalement le Vendor ID d'un ONT est censé être les 4 premières lettres du SN.
Sur l'ONT FS, c'est un réglage séparé.
sfp_i2c -i7 -s ALCL
Si ça ne fonctionne pas, l'étape suivante serait de mettre Hardware Version (les OLT ALCL Orange font la vérification, mais pas ceux de Bouygues normalement).
C'est dans /etc/mibs/data_1g_8q.ini (ou data_1g_8q_us1280_ds512.ini si tu as changé mib_file).
256 0 HWTC 3FE47211DHAA\0 ...

firstboot ça efface les modifications faites sur les fichiers et configs OpenWRT.

Là à moins que tu aies fait d'autre manipulations, l'erreur de sfp_i2c suggère un problème avec la variable u-boot sfp_a2_info.
Que donne "fw_printenv sfp_a2_info" ?

https://hack-gpon.org/ont-fs-com-gpon-onu-stick-with-mac/ indique "GPON Vendor ID (ME 256 and more), may not work in some firmware".
Donc peut-être que l'erreur que tu vois est "normale", on peut vérifier le Vendor ID exposé avec "omci_pipe.sh meg 256 0" (s'il est correct, alors il est dérivé directement du SN, et ça expliquerait que le réglage séparé ne fonctionne pas).

Au cas où, quelle est la version du firmware ?
strings /opt/lantiq/bin/omcid | grep ^software_Version | awk -F[=,] '{print $2}'

Tu n'as fait aucun backup ?

Pour fw_printenv, "Cannot parse config file" semble indiquer que /etc/fw_env.config manque ou est incorrect.
Il est créé par "/etc/init.d/fw_env.sh boot".
Là je pense que c'est juste un effet d'avoir lancé "firstboot" et de ne pas avoir rebooté depuis.
En revanche si sfp_i2c a commencé à avoir l'erreur avant, je ne sais pas trop dans quel état est l'ONT.

Les variables u-boot ne sont pas dans le firmware, c'est une partition à part.
Et il ne faut surtout pas les écraser, dedans il y a les données de calibration qui sont uniques.

Si le sfp_a2_info n'a pas été modifié, je ne comprends pas comment le password aurait pu changer.

Du coup soit tu es dans un cas où le SN+vendor id suffisent (si les VLAN sont là), soit il faut remettre de password.

Il y a un "sfp_i2c -d yes" au boot dans /etc/init.d/sfp_eeprom.sh, "reset to default values", qui est bizarre.
Donc je ne sais pas dans quelles conditions les valeurs pourraient être réécrites.

Là tu as le SN + Vendor ID, parfois ça suffit : "omci_pipe.sh meg 131 0" et "omci_pipe.sh meg 171 0" pour tester.

Si tu n'as toujours pas les VLAN, alors il faut remettre le PLOAM password (je ne sais pas trop comment il s'est perdu).