The overall behavior is caused by systemd, even if systemd isn't configured to manage the system's network.
A bridge interface on Linux has two "modes" with its MAC address:
the implicit mode
When creating a bridge interface without specifying its MAC address, it gets a temporary random MAC address (with private bit set). When an other interface is set as bridge port, the bridge inherits this interface's MAC address to replace the temporary one. I leave undefined what happens when a 2nd interface is added because behavior might have changed depending on kernel version. This mode can't exist anymore on a system with a recent systemd running.
the explicit mode
When creating the bridge (ip link add ...) or changing it (ip link set dev ...) one can specify address xx:xx:xx:xx:xx:xx, changing the bridge's behavior: it won't inherit anything, its initial oper state will be down when administratively set up (because it has no connectivity yet) instead of unknown and a few similar things. For example by indirect effect such bridge won't have a link local IPv6 address created since it's in down oper state, until it has actual connectivity using an added bridge port itself with connectivity.
systemd
Recent versions of systemd choose to always explicitly assign a MAC address to virtual interfaces that were created without specifying the address (systemd tracks this. One can track what it does by running ip monitor link and see that the interfaces created without stating the MAC address immediately get their MAC address changed (by systemd)). systemd doesn't care (at least by default) if it's supposed to manage the interface or not.
This affects bridges. Because the algorithm choosing the MAC address depends on the system's machine-id UUID (and the interface name), if the system-cloning actions don't change the machine-id, two systems will keep the same MAC addresses on their virtual interfaces with the same name, such as br0. These two systems won't be able to communicate properly anymore over their LAN since there must be no same MAC address on an Ethernet LAN (and this might cause some switches in the path to complain and log flapping errors).
This systemd behavior is visible in the host initial network namespace but not in other network namespaces (unless they have systemd also running on it like would be the case in a system container managed by LXC), because systemd won't track other network namespaces.
Solutions
As systemd doesn't look like it will disappear soon, the best way is to stay compliant with what it does: have an unique machine-id provisioned on each cloned system. The method to change the setting for each clone is explained for example there (and is not specific to Debian, but to using systemd or one of its sub-components):
machine id and cloned systems, generating a new machine id
The machine id is something that is frequently missed to change when
cloning a machine. A new machine-id can be generated by
rm -f /etc/machine-id /var/lib/dbus/machine-id
dbus-uuidgen --ensure=/etc/machine-id
dbus-uuidgen --ensure
Making /etc/machine-id a 0-byte file is considered to be the canonical
way to clear it, rather than actually deleting it, because if systemd
is running on a completely read-only root filesystem, it has code to
create a machine ID on a tmpfs and bind-mount it over the top of the
empty file.
So either execute the 3 commands above and have a way to automate this (eg: using ansible which could compare with the deployed id present by default), or just remove files and create an empty /etc/machine-id hoping systemd will do some randomization (if not R/O, no idea how this later method behaves).
Of course doing a manual assignment of the MAC address won't be overridden by systemd. So as long as the value is different on each system, one can set the address when creating the interface. With the ifupdown package and bridge-utils installed (because it provides additional functions to ifupdown, not really for the obsolete brctl command) you can use the function bridge_hw in the bridge stanza.
You can either copy the real interface's MAC:
bridge_hw enp0s31f6
so that for example DHCP without DUID behaves the same as it would have without a bridge configuration, and as an added bonus, defer the choice of an unique MAC address to the hardware (ie: the NIC manufacturer or for virtual systems the hypervisor).
Or you can choose a different MAC address on each system:
bridge_hw 12:34:56:78:9a:bc
For more details and reproducible examples about this "feature" of systemd and how it affects bridges and other virtual interfaces, see this UL SE Q/A where I made an answer:
How can I make Linux generate different MAC addresses for different bridge devices which are on different PCs?
