The situation around Realtek wireless drivers, particularly USB wireless drivers, is an utter mess. Realtek pushes out new, slightly changed, wireless chipsets 2-3 times a year, each with their own vendor driver[0], which is subsequently forgotten about immediately, in favour of the next one - but doesn't follow up with upstreaming them at all[1]. For a while these drivers were accepted into staging, but after six drivers ended up there[2], rotting away without ever getting closer to being mainlined, staging is no longer accepting[3] new drivers of this particular kind.
This means the drivers remain unsupported upstream[4], with random github users adopting the vendor drivers and keeping them on life support for their own needs - which means you end up having to choose between different kind of bugs, depending on the 'best' source of the day. None of these drivers support AP mode at all[5].
Aside from doing this properly, by mainlining (mainline, not staging), there is no way forward for these drivers. Given the pain and invasive nature of the required efforts to (potentially) getting them working under OpenWrt[6], trying to support these for OpenWrt wouldn't be a reasonable effort.
--
[0] each coming with their own ~2.6.16-era ieee80211-softmac derived wireless stack, each exporting the same -conflicting- symbols to the rest of the kernel
[1] the situation for their PCIe devices is slightly better, not good, but better
[2] only a single PCI based Realtek WLAN driver (rtl8187se, aka rtl8185b) ever made it out of staging (absorbed into the existing rtl8185 support of the rtl8180 driver)
[3] https://lkml.kernel.org/r/20190515163945.GA5719@kroah.com I recommend to read the whole thread
[4] unless someone does the heavy lifting to porting support for the devices to rtl8xxxu
[5] that's a lie, but each needs its own patched hostapd 0.4.8 (the current version would be v2.9) derived fork, with a custom driver backend and a wext like userspace interface; none of this supported or supportable in OpenWrt
[6] yes, it would be easier if you only care about a single one of them and are fine with changes that would break the others - aside from that, you'd have to actively put your head into the sand and ignore the security implications of running an abandoned 14 year old hostapd codebase…
So I guess its pointless,
I just need to find a good adapter based of some chip natively suppored in the 5.4.143, kernel