I know this is an old post however, I'll add my two cents anyways for whatever it is worth. When I first started down the SDA journey 2yrs ago Cisco TAC flat out told me that wireless PtP links were not supported with SDA and consequently they wouldn't help with this deployment type at all. However, that answer was not good enough for me as I have multiple small FIAB deployment sites where our only option was wireless PtP links. My design at these sites was similar to your option C deployment, as the FIAB Border device is located at our ISP Dmarc location and the sites had multiple small outbuildings for specific user functions, installing fiber/cat cable between these buildings is/was extremely cost prohibitive when you are talking about 2-3 computers and a wireless AP with a few clients. To make this work:
Your PtP wireless bridge devices have to support MTU adjustments above 1500, we were using Ubiquiti Nanostation AC devices for this, and they will support an MTU up to the max RFC MTU ~2400 for wireless (Ubiquiti does not recommend this either but, it does work) at these locations we ended up settling on a 2000 MTU for the entire fabric site and was a balance between SDA requirements and wireless packet size, this all has to be manually configured (Note we do not use any lan automation at these sites either due to the fact that it does very little for initial border deployment and we only had a need for 1-2 Edge switches at the sites we use base deployment templates for all of these devices and manually install/configure the base before shipment. Once the devices are online and connected we then push the fabric config to the devices.
Another thing to consider is that true SDA only uses routed links on the Edge nodes however, regardless of what Cisco says we have multiple devices we have to support that just will not work in the SDA environment be it DHCP delays or non RFC spec controllers etc... so we ended up configuring our underlay on the switches connected to an SVI and having ISIS configured on the SVI for overlay routing and we are passing L2 VLANs in the underlay beneath the overlay at the same time. Yes, this does not solve the STP problem however, if STP is done properly with no redundant links it can be controlled. In practice this has not broken anything but, does prevent CatCtr/DNAC from being able to act as advertised.
That said, this does not align with any of the Cisco CVDs and is likely not supported by TAC if you have any issues. I would not recommend attempting the deployment I described without fully understanding the underlay/overlay relationship. However, I can say that it can be made to work and support your needs. Good internal documentation and training whomever is maintaining this environment is required.
To be honest, I really like the features of SDA for 90% of things however, for my current needs it is not 100% viable rip and replace solution with no native L2 support (L2 handoffs and flooding) have not resolved the issues with these devices nor have the addressed supporting the 10% of devices that are required. Cisco really needs to make sure that people understand that not everything in the world works with a true SDA only network before they sell it to them.
