If you don't set a PVID on the ether1 bridge-port, then it will use PVID 1, and any untagged traffic received on the port will be assigned to vlan 1 on the switch (or virtual switch if it is being done in software). I don't know if this can be modified by a switch rule or not, but I don't think switch rules "work" in a software only bridge implementation.
Can you explain why you don't want to set the PVID manually? Is it because you only want to have one line that is controlling both functions?
If that's the case, when you set the pvid on a bridge-port, in v7.15+ it dynamically adds the vlan as untagged in the /interface/bridge/vlan line for the vlan. Before that it wasn't mandatory to add untagged, but it was only visible when you used /interface/vlan/print detail (see this) This has been true for a while (all versions of 7 that I have used). v7.15 reworked it and now gives more info about the dynamic entries, and what triggered them to be added.
You can see this with the CLI command: /interface/bridge/port/print or if you use export verbose, you will see the pvid=1 in the bridge port settings.
And it is ROS v7.16+, when you create a vlan interface under the bridge, then it will dynamically add the bridge as a tagged member for the vlan.
You can see this with the CLI command: /interface/bridge/vlan/print
With ROS v7.16+ you aren't required to use the /interface/bridge/vlan unless you want to configure a vlan that isn't being routed, i.e. just being bridged at layer 2 with no connection the routing engine (CPU). So it is still a requirement when configuring a device as a switch where only the management interface is "connected" from the CPU to the switch so the router sees only a single interface with ip address and therefore can't can't route.
The IEEE 802.1Q standard requires every bridge-port to have an non-null PVID. There isn't the requirement that that multiple vlans can't egress from a bridge-port untagged. That's a requirement for asymmetric vlans (which also requires shared vlan learning (SVL), i.e. the "key" to the mac table is just the mac address; this implies that you cannot two devices using the same mac address on two ports, otherwise there will be a lot of thrashing of the port associated with the mac address. ROS only supports independent vlan leaning (IVL), so you can't configure asymmetric vlans with ROS (at least I am not aware of a way to do it). On ROS with IVL, the lookup key for the mac address table is the mac_address+vlan_id, so it is possible to have two devices using the same mac as long as they are in separate vlans, and they won't "collide", e.g. mac abcd on vlan 5 (on port ether3) will have a different mac address table entry than mac abcd on vlan 6 (port port ether2); the mac address table will have more entries for bridge-ports that are members of mulitple vlans. The purpose of asymmetric vlans is to allow for client isolation, and ROS uses a different way to achieve that goal (switch -> port isolation -> forwarding-override)