OK, but to avoid further tampering with the remote access, I’d now keep ether1 and VLAN 111 on bridge_EXT and migrate other ports from bridge_PVE to bridge_EXT, and once bridge_PVE becomes empty, remove it and rename bridge_EXT to bridge_PVE.
Indeed you have to manually add ether2 to the tagged list on the /interface bridge vlan row for vlan-ids=111 on bridge_EXT (but the print output suggests you have already done that).
If you enable ingress-filtering and only make each port (“ether2” in this example) a member of the VLANs you want it to handle (VLAN 1 and VLAN 111 in this example) using the appropriate settings in /interface bridge port and /interface bridge vlan subtrees, it doesn’t matter much whether one of the allowed VLANs is set in access (tagless, untagged) mode on that port or not. So security-wise, switching the “LAN” VLAN 1 on ether2 to tagged (trunk) mode is only optional, and so is changing the VLAN ID to something else than 1. But if you opt for the latter, it must be done properly, i.e. you must either change the pvid in the configuration of the bridge to that “something else” or you must add another VLAN interface to the bridge with that “something else” as vlan-id). I assume you are familiar with the concept of a “virtual switch”, “virtual router-facing port of the virtual switch” and “virtual bridge-facing interface of the router” as explained here, i.e. that you understand the role of the pvid parameter in the bridge settings).