One extra data point on the version split you are seeing, in case it helps narrow it down.
In the thread JosephS linked above (https://forums.openvpn.net/d/46607), another user traced the same class of behaviour to the client's own config.json rather than to the imported profile: multiple remote entries only get tried while "selectedServer" stays null, and saving the profile through the GUI rewrites it to the first server in the list. That is consistent with what you found, because saving only the username is still a profile save, so the password path does not have to be involved at all. Making config.json read-only is reported not to help either, the app errors instead.
If you want to confirm it on a machine that is currently failing rather than infer it: open that profile's config.json in the OpenVPN Connect profile directory and check whether selectedServer is null or pinned to your WAN2 entry, then compare with a machine that still fails over correctly. That separates a pinned server from a timeout-tuning problem, which is worth knowing before changing anything else.
From the log side: on a failing run, does the log ever show a resolve or connect attempt for the WAN1 address, or does it only ever retry WAN2? Never mentioning WAN1 at all points at the pinned-server path rather than the client abandoning the first remote too slowly.
On keeping this usable without saved credentials, one server-side option worth considering since you control both pfSense servers: auth-gen-token. Adding auth-gen-token <lifetime> to the server's custom options makes the server issue an HMAC-protected token after a successful RADIUS authentication and push it to the client; the client then presents that token instead of the password on renegotiation, and the server validates it internally rather than going back to RADIUS. It does not remove the first prompt of a session, but it removes the repeated ones, with nothing stored on the workstation. The external-auth flag exists for the case where you do want your RADIUS backend consulted on every verification, so decide which of the two behaviours you want before enabling it.
The other angle is to stop relying on the client's remote list at all: publish one hostname for the service and let DNS decide which WAN is live, with a short TTL and a health check, so the profile carries a single remote entry. That moves the failover decision off the client version entirely, which given the state of this bug is the more predictable place for it. If you try that, measure how quickly your clients actually pick up a changed record, because a cached address will delay recovery by roughly the TTL.
