av4625

@av4625 
there is one experiment that I did not try which is to play with wpa_supplicant with its own /etc/wpa_supplicant.conf 
if it works, it'd likely point to a problem in network manager itself, possibly that network manager is sending the 'wrong' commands.
 
However, as I couldn't figure out how to work that with network manager, possibly conflicts since network manager is intended to control it via the unix socket?
redoing the 'whole' thing by having network manager unmanage the wifi interface is another test, but I did not try that due to the effort involved.
 

@av4625 
here are some of my thoughts, as discussed prior, wpa_supplicant and / or hostapd is The 'library' that does *all* of WPA/WPA2/WPA3
https://w1.fi/wpa_supplicant/devel/
The design goal for wpa_supplicant was to use hardware, driver, and OS independent, portable C code for all WPA functionality The design goal for hostapd was to use hardware, driver, and OS independent, portable C code for all WPA functionality.  
That means selecting either wpa_supplicant or hostapd would provide the wifi AP functionality specifically for WPA / WPA2 and authentication.
Using hostapd apparently has 'better' logging as the access attempt is logged 
journalctl -u hostapd there are some messages, some abstracts from my logs
STA mac_addr IEEE 802.11: associated STA mac_addr RADIUS: starting accounting session 63AA93B230BE083E STA mac_addr WPA: pairwise key handshake completed (RSN) STA mac_addr WPA: group key handshake completed (RSN) STA mac_addr IEEE 802.11: disassociated this helps ascertain that the connection / WPA / WPA2 is established and authentication is successful
 
From prior discussions, it seemed NetworkManager uses wpa_supplicant. In my case, I find the lack of logs 'opaque' and lacks info for adequate troubleshooting.
I'm also unsure if I can adequately separate the concerns with Network Manager with an AP, i.e. hostapd itself (for WPA/WPA2 and authentication), then dhcp to provide (to connecting clients) ip address and dns address, ipv6 router advertisements etc and in addition to setup a bridge separate from the wifi interface itself.
And in part, hostapd apparently provides significantly more detailed configuration, in particular for the various features supported by wifi itself.
https://web.mit.edu/freebsd/head/contrib/wpa/hostapd/hostapd.conf
Hence, I choose to use hostapd instead.
However, given those documentations, https://w1.fi/wpa_supplicant/devel/, it'd seem that hostapd and wpa_supplicant are likely equivalent. just that i'm more familiar with hostapd currently.
 
Hence, in my setup. I've Network Manager omit setting up the wifi interface.
 /etc/NetworkManager/conf.d/99-unmanaged-devices.conf
[keyfile] unmanaged-devices=interface-name:wlan0  
Network manager, however, is used to setup the bridge and manage the ethernet interface, configured using nmcli.
Then hostapd is configured to patch the wifi interface into the bridge after hostapd is running.
/etc/hostapd/hostapd.conf
bridge=br0  
Networkmanager configuration of the bridge looks like this
> nmcli c NAME UUID TYPE DEVICE bridge d0fc7d8a-51ea-4c5d-a297-943e2a037cff bridge br0 lo 59201f46-2fff-4f67-9822-7019cea62cf5 loopback lo br-eth 29c02c5c-4d75-4e03-bb71-8a761e076562 ethernet end0 > sudo brctl show bridge name bridge id STP enabled interfaces br0 8000.xxyy yes end0 wlan0 Here, wlan0 is patched into the bridge by hostapd. Note the race condition issue discussed 3 comments prior.
 
The ethernet connection should be visible in NetworkManager in the default configuration e.g. as "Wired connection 1"
 
Then to setup the bridge I used a bunch of nmcli commands
https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3
nmcli con down "Wired connection 1" nmcli con del "Wired connection 1" nmcli con add connection.id bridge type bridge ifname br0 nmcli con add connection.id br-eth type bridge-slave ifname end0 master br0 #this is for dynamic (dhcp IP address) #nmcli c modify bridge ipv4.method auto #this is for fixed ip address, and assume that your gateway router is at 192.168.1.1 nmcli c modify bridge ipv4.method manual ipv4.addresses 192.168.1.10/24 ipv4.gateway 192.168.1.1 In the above I removed the default Ethernet connection and replaced that with a bridge setup.
The above can only be done via a 'usb-uart serial debug' bridge/dongle on the 3 serial pins for the serial console. i.e. you can't work from ssh into the ethernet connection and change the network configs.
 
This is for the bridged setup. For a routed setup, my thoughts are that the 'missing' things are 
configure ip address and routing for the wifi (wlan0) interface (this would need to be done outside NetworkManager if it isn't managing it) run a dhcp server to provide connecting clients with ip address and dns address (this can be provided by dnsmasq or a dhcp server (e.g. isc-dhcp-server). 
(other services to run can included ipv6 router advertisements (radvd or dnsmasq does that), avahi (multi-cast DNS) etc) configure 'upstream' routing / forwarding through the ethernet (end0) Those are covered to some extent in the prior discussions.
 
If you managed to run a succcessful setup say with hostapd, my guess is that you could likely migrate/convert that into a completely NetworkManager setup which uses wpa_supplicant internally.
It could possibly be 'less verbose' as compared to these setups which requires a lot of additional manual configuration as like above.
 

Looks like dnsmasq is running. I get that failed message in my log, too, so you can ignore it.
 
According to your 'ip -4 add' output, it doesn't appear the wlan0 interface is getting assigned the 10.10.1.1 address like it should from the hostapd.service file.  Based on the 'systemctl status hostapd.service' output, the ExecStartPre commands in that file that set the address aren't being run.  What's the output of 'cat /etc/systemd/system/hostapd.service'?

it seemed possible that WPA is used after all (even with hostapd)
wlan0: STA mac_add IEEE 802.11: associated wlan0: STA mac_add RADIUS: starting accounting session EC98EEE1B63146E8 wlan0: STA mac_add WPA: pairwise key handshake completed (RSN) wlan0: STA mac_add IEEE 802.11: disassociated  
I'm using
wifi-sec.key-mgmt wpa-psk as well
 
the documentation shown with "describe" command in your run literally says "wpa2 + wpa3 personal", but it seemed wpa is used instead
 
in my hostapd.conf
# 1=wpa, 2=wep, 3=both auth_algs=1 # WPA2 only wpa=2 wpa_key_mgmt=WPA-PSK rsn_pairwise=CCMP  
it is uncertain here if that message literally means wpa or that actually wpa2 is used. 
https://wireless.wiki.kernel.org/en/users/documentation/hostapd
 
apparently RSN is probably WPA2
-----
apparently there is one more configuration option in Networkmanager
https://people.freedesktop.org/~lkundrak/nm-dbus-api/nm-settings.html
Table 30. 802-11-wireless-security setting
pairwise array of string [] A list of pairwise encryption algorithms which prevents connections to Wi-Fi networks that do not utilize one of the algorithms in the list. For maximum compatibility leave this property empty. Each list element may be one of "tkip" or "ccmp". proto array of string [] List of strings specifying the allowed WPA protocol versions to use. Each element may be one "wpa" (allow WPA) or "rsn" (allow WPA2/RSN). If not specified, both WPA and RSN connections are allowed.  
based on these descriptions it is likely that if "proto" is not specified both wpa and wpa2 (RSN) is allowed.
 
my guess is the connecting device (e.g. phone)  would choose the preferable more secure protocol e.g. wpa2
 
nevertheless, you may like to tweak them to see if that helps