That's become sort of common lore in FreeBSD. I still have to sit down for a beer with e.g. George Neville-Neil and/or Kristof Provost to get a complete picture but whenever something goes awry with stacked layer 2 features like bridge on top of vlan on top of lagg on top of physical ... the first question is always "did you disable HW offloading?".
There's some logic to that because e.g. TCP checksum offloading to the physical card is a layer violation in the above example. We have multiple levels of layer 2 decapsulation before the packet should even hit ip_input() in the kernel.
OTOH there are mechanisms in e.g. the bridge code that remove IPv6 addresses from member interfaces as soon as they are added - because that would pose a scope violation and the address belongs on the bridge interface. So I could envision a similar mechanism for all this other stuff that needs to be disabled as soon as an interface becomes part of a bridge. Or a lagg. Or whatever.
I even had a regression like that with a virtual instance (DigitalOcean droplet) and PF NAT. What the ...?

Disabling the HW features like you did and everything was fine. On non-existing "cloud" hardware ...
So glad it's working now. There is definitely work to do in this area in FreeBSD land. And though I cannot code I can write proper bug reports or hint at the Foundation about priorities (coupled with a donation that does work, folks!) ...