@Justine Smithies
What seems to causing this would iwlwifi cannot hear 11a beacon, thus, falling down to 11g.
Some possibilities I can think of is:
Noises in 5GHz bands (usually not, unlike 2.4GHz that conflicts
with microwave ovens, BlueTooth, and some others).

Depending on regdomain, 5GHz range have allowed but restricted channels
unless checking other signals in use (radars, typically) and need wait.

Conflicting with neighborhoods' APs and defeated.

@Justine Smithies
What happenes if you add (just an example, edit to match yours) below in network={ } block of your /etc/wpa_supplicant.conf?

key_mgmt=WPA-PSK
proto=RSN

And outside (prior to) the network={ } block, adding below, if you've not?

ctrl_interface=/var/run/wpa_supplicant

@Justine Smithies
Does re1 alone (without configuring lagg) work?
If yes, does it take long time to link up including DHCP? If so, possibly lagg0 is too early to be started up (sorry, not sure how lagg can be delayed).

And at the moment when I've configured lagg, wpa_supplicant was simpler (and I couldn't find no other reachable APs around me) than now and "WPA" was sufficient, but maybe it's insufficient now. I.e., fixed (preferred) SSID if you have multiple ones in your {/usr/local}/etc/wpa_supplicant.conf, regdomain, mode and so on.

If the slowness on negotiations with DHCP is the issue, and you can somehow configure DHCP server to supply fixed IP address for the specific MAC address, doing so and intentionally configure your PC to use fixed IP address and other configurations the DHCP server supplies could help.

@Justine Smithies
I'm not configuring #lagg for years, so things could be changed, but when I've configured lagg for failover before, MAC addresses of all member interfaces needed to be exactly the same. So I've adjusted MAC address of WiFi to be the same as wired. Below is the remnant of the era (addresses hidden, using em0 [wired] and iwn0 [WiFi] as members).

## Network configurations for failover using lagg
ifconfig_em0="up"
ifconfig_iwn0="ether *:*:*:*:*:*"
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 *.*.*.* netmask 255.255.255.0"

@nprofile1q...
Making web.archive.org (Wayback Machine) as "only single service that is allowed to crawl using robots in the world" and any others commercially want to use data on Internet to purchase data from them (of course, only allowed to do ones. Would need i.e., "no AI, no commercial" option in robots.txt not to be sold to AI things) seems to be the way to go.
And force purchasing data from Wayback Machine to be outside Internet (dedicated leased line, for example) would significantly lower the unndeeded traffics.
Keeping Wayback Machine in good manner (strictly obbey robots.txt, restricting crawling frequencies, contracting with authors directly by Wayback Machine if contents are allowed to be sold, and so on) would be needed, too.
This way, all "allowed" contents that are not too often (over once a day, for example) to be updated could kept public even when the server services are gone disregarding the intentions of authors there.

@nprofile1q...
Take care of yourself and your family!☕

@nprofile1q...
Unfortunately, pre-AX series of WiFi chips are NOT supported by iwx driver.😭
And for Gtk, the problem is... eh ... who can do it?😅

@nprofile1q...
I vote for Gtk3. Better works on HiDPI than Gtk2.
At first, Gtk3 struggled from unacceptable slowness of files dialog (especially there are large directories or network shares), but already fixed by updated glib20.

And for WiFi drivers, the effors are started with iwx driver (implememted on OpenBSD and shared to FreeBSD). Hope this effort grows up.

@nprofile1q...
If systemd / logind dependants is the login manager only and KDE project don't plan to extend the dependencies to systemd / logind, it would NOT be a large problem.
FreeBSD KDE team would need to replace default login manager for KDE to something don't depending on systemd / logind && can kick KDE, and that's all.
But if not, Mate DE should be way to go, if anyone possible fork Gtk3 keeping maintainance and Mate project switches to it when Gtk3 is obsoleted.
Possibly Gtk4 could be candidate, but upcoming Gtk5 would NOT, as of stated deprecation of X11 support.

@nprofile1q... @nprofile1q...
Because regular European users do NOT need CJK inputs, which is MANDATORY for me but never succeeded to be configured to work. Isn't it?
Of course, X11 is OK.

@nprofile1q...
..."Management system" in human side (like ISO9001, ISO14001,...)?