In theory that has nothing to do with bridge mode (none, STP, RSTP, MSTP). Bridge mode is about loop detection (and blocking ports where loops are detected).

What you see is likely effect of improper FDB[*] handling and/or L2 hardware offload. The basic functionality of a bridge (or switch) is that it only forwards frames to ports where destination is reachable. Only if destination whereabouts are not known then frames are "flooded" to all bridge/switch ports.

[*] FDB (a.k.a. Forwarding DataBase) contains mapping between destination MAC address and port which connects towards that MAC address. Until bridge/switch sees a frame with src-mac-address and notes ingress port, FDB doesn't have matching entry. After receiving it, FDB gets updated and frame "flooding" stops.

L2 HW offload can affect the "visibility" as well, bot not exactly the traffic direction you mention. If L2 HW offload is enabled, then traffic between a pair of bridge/switch port will not pass CPU (it'll be handled by switch chip), so sniffer or torch will not see such traffic. However this doesn't affect visibility of traffic between external port and device CPU.

But anyway, changing configuration of bridge (e.g. mode) can flush buffers/tables/etc. and intermittently bridge/switch may seem to operate in a completely different manner. Another possibility (rare, but seen a few times) is that bridge/switch config is improperly applied to hardware (in case of L2 HW offload) ... sometimes cold boot (i.e. power off device for a few minutes) fixes it, sometimes it's actually ROS configuration database (internal binary blob) which gets corrupt and in that case some radical configuration cleansing needs to be done (e.g. netinstall and reconfiguration by using CLI/GUI, without restoring binary backup).