So if I get you correctly, you've got a public subnet on the uplink from the ISP, and you want to extend that public subnet all the way to the comunity centre via the P2P link, whilst there is one more hAP ac2 between the one connected to the uplink and the SXTsq at your end?
If so, VLANs are one possible answer indeed. There's
the great VLAN tutorial by @pcunite; there's also
the clarification of the sometimes confusing vernacular regarding the bridge. Roughly, you'd make the physical WAN port on the hAP ac2 a member of the common bridge with
pvid=10 (you can choose any number between 2 and 4094 inclusive), attach an
/interface vlan with
vlan-id=10 to the bridge and move the WAN IP configuration from the physical WAN port to the
/interface vlan. This involves also addition of that
/interface vlan item as a
member of
/interface list WAN so that the firewall rules worked as before. On all the ports on the path from your internet-facing hAP ac2 to the community centre's hAP ac3, VLAN 10 would be permitted as a tagged one. And the hAP ac3 would use another
/interface vlan with
vlan-id=10 as its WAN.
This solution is a clean and "traditional" one; however, bandwidth control on L2 is far from traditional in RouterOS, so it can easily cause a headache. Therefore you may prefer to use a "forth-and-back" NAT, using firewall rules that dst-nat whatever arrives to the CC's public address to some auxiliary private address, route that address towards the hAP ac3 and dst-nat it back to the public IP there (which may not be actually necessary, it depends on what they need the public IP for). You also have to use appropriate src-nat rules for connections initiated from the CC side. Whilst this method is "dirty", it allows you to implement bandwidth control at L3, which is somewhat easier, and it also permits not to use VLANs at all, although separating your LAN subnet from the interconnection subnet between internet-facing hAP ac2 and the hAP ac3 by means of VLANs is definitely recommended.