Ok so we managed to solve the problem.
In short in our setup we did not need dhcp relay (i.e. since there is no routed hop between dhcp clients and dhcp server) - we are using MPLS VPLS/pseudowire.
Now on a typical PE the VPLS interface carrying the dhcp service was already added to the single bridge hosting vlans (refer to mikrotik bridge vlan filtering). So we proceeded to set the bridge ports facing the path to dhcp server (i.e. vpls interface) as trusted and the access ports facing client CPEs (i.e. AP-Bridges and Station-Bridges as untrusted.
We then enabled dhcp option 82 on the bridge (dhcp-snooping=yes add-dhcp-option82=yes).
Referring to Peters reference on how Splynx handle dhcp option 82 we enabled the remote-agent-id on customer services and also turned on debug to see what remote-circuit-id and remote-agent-id was received by splynx radius. An alternative to debug is to see the lease parameter values - agent-circuit-id and agent-remote-id in the mikrotik dhcp-server (i.e. /ip dhcp-server lease print detail). In our case the values were agent-circuit-id=“pe01.someisp.net eth 0/6:187” agent-remote-id=“ether6” , where pe01.someisp.net was the system identity of the closest PE gateway to customer. eth 0/6:187 indicated vlan187 on the single bridge with all vlans with ether6 as a bridge port on which AP-Bridge serving customer is connected on that PE. We noted that with bridge vlan filtering its NOT necessary to create a bridge for every vlan. Infact ether6 had pvid different from vlan187.
Finally we use an ASCII to HEX converter and vice versa to verifiy and convert values.
Since Peter pointed out that MAC and Port ID (agent-circuit-id) parameters in splynx customer service settings are mutually exclusive, the challenge now is how to differentiate dhcp assignments to customers hooked to the same AP-bridge connected to the same PE port. Putting every customer on a different vlan is not scalable. Any ideas?