I'm afraid it came to nobody's mind that a single bridge could host multiple customers' bgp-vpls tunnels and hence VLAN tag manipulation would be required on the port of the bridge to which the tunnel is connected, hence the pvid is not part of the /interface vpls bgp configuration. The designers probably expected VLAN tag manipulation to happen at edge ports, not tunnel ones.
So as you apparently cannot accommodate to that concept, try to unset the bridge item on the /interface vpls bgp row, which will make that dynamic entry disappear. Then, add an /interface bridge port row manually, with the pvid you need. It may not be possible at all - the name of the tunnel may not be offered as an interface name to add as a bridge port. Even if it is possible, I'd assume that once the tunnel disappears and re-appears, the /interface bridge port row will say interface=*some-hex-number and the traffic will not flow to/from the tunnel, so you would need a script tracking the changes and updating the /interface bridge port list accordingly. But first check that it actually works - PPP BCP adds L2 tunnels as bridge ports dynamically as well, but vlan-filtering doesn't work at all on these ports (I don't remember whether it's just that tagged frames are not received from the tunnels or something worse).
If the bgp vpls tunnel cannot be added as a bridge port this way, you have to keep using your interconnected bridges, and maybe use /interface bridge filter rules to prevent the bad things listed at the "don't do this" page from happening (e.g. not allow STP BPDUs to leak through the /interface vlan to the main bridge). And convince the developers that your use case is so common that it makes sense to implement the corresponding handling.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.