With the new bridge and HW offload, do you think it would be possible to configure manager forwrding whilst still using the switch chip to get wire speed?
I'm afraid there is no difference. The new bridge implementation changes nothing in hardware, it just changes the way how the user configures the Ethernet ports of the switch chip belonging to the same bridge. The "old" way, you chose one "master" port and made it a member of the bridge, and the other member ports of the same bridge on the switch chip were marked as "slave" ports of the "master" one rather than individual member ports of the bridge. The "new" way, you make all ports members of the bridge, and the RouterOS automatically switches on "hw-offload", which actually means switch chip forwarding between member ports on the same switch chip if other pre-requisites are met.
But the wireless interface has no direct path to the switch chip, so the frames from the wireless module to the switch chip are always forwarded by the CPU, regardless whether old or new bridge implementation is running on the same hardware.
A small speed-up might be obtained if you would use local forwarding, where the frame received from the wireless interface would be sent to the switch chip already at the cAP and then forwarded to its L2 destination directly, whereas in case of manager forwarding, the frame is first encapsulated into UDP, then sent to the switch chip, delivered to the manager, unpacked from UDP there and sent to the manager's switch chip again and forwarded to its L2 destination from there. But this obviously only makes a difference where the L2 destination is not the manager so the frame only passes through the switch chip and CPU on the cAP with local forwarding, as compared to two passes through a switch and CPU with manager forwarding. If the L2 destination is the manager, the only difference which remains is the encapsulation and decapsulation to/from UDP.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.