Additional day's worth of usage has revealed the following gem in the log files:
------------------------
2024-02-15 00:51:07 Led Controller INFO [1690] Start to run WAN0_ON
2024-02-15 00:51:06 Led Controller INFO [1690] Start to run LAN_ON
2024-02-15 00:51:04 Led Controller INFO [1690] Start to run WAN1_OFF
2024-02-15 00:51:04 Led Controller INFO [1690] Start to run WAN0_OFF
2024-02-15 00:51:04 Led Controller INFO [1690] Start to run LAN_ON
2024-02-15 00:43:15 Led Controller INFO [1690] Start to run WAN1_ON
2024-02-15 00:43:15 Led Controller INFO [1690] Start to run WAN0_OFF
2024-02-15 00:43:15 Led Controller INFO [1690] Start to run LAN_ON
2024-02-15 00:43:12 Led Controller INFO [1690] Start to run WAN1_OFF
2024-02-15 00:43:12 Led Controller INFO [1690] Start to run WAN0_ON
2024-02-15 00:43:12 Led Controller INFO [1690] Start to run LAN_ON
2024-02-15 00:43:10 Led Controller INFO [1690] Start to run WAN1_OFF
-----------------------
So, first, it should be pointed out that TP-Link's log file level is unreasonably low (as in, does not remotely log enough). Folks have complained about this elsewhere. The above series shows brief WAN outages and restores at 00:43:10 to 00:43:16 and later at 00:51:04 to 00:51:07. What actually happened here is WAN link went down, briefly, and router seamlessly reconnected, AS IT SHOULD BE! These same brief outages, as you can see in my other thread, would completely p0rk the ASUS DHCP WAN stack and it would never reconnect. I would have woken up today to internet being "down" and would have had to do a bunch of troubleshooting before my first work meeting. Instead, it Just Worked™.
Of course TP-Link should be slapped on the wrist for only logging LED controller responses for a WAN outage; obviously they should be showing the actual WAN stack actions in the log, but for my use case, this solves my longstanding issue with two generations of ASUS routers' defective DHCP WAN stacks that have made my life and that of my family miserable for years.