The viability of the link with your calculated 1392 MTU in both directions is indeed tested during the HELLO exchanges, as those initial packets are fully padded to that size, independent of actual payload quantity. Although this is far from a fool-proof method of validating MTU (and MTU can change dynamically with routing etc.), it empirically works well.
The value seen in the code was selected after a lot of experimentation with real-world traffic and path patterns. It represented a compromise between reachability (smaller packets sizes get through in more scenarios), and efficiency (larger packets waste less bandwidth on overhead for a given payload.
It is also good to keep in mind that QUIC was designed to fall-back to TCP when a connection cannot handle the traffic (especially the HELLO negotiations). This is, for instance, a notably problem if a user has a firewall blocking UDP traffic on the ports that QUIC utilizes (it is not a "frequent" problem, but it has to be dealt with). This need to fallback then works to cover the case where MTU problems preclude, or degrade (demolish?) a connection.
Jim