Either I'm not following you or I'm being unclear - it doesn't matter what HTTPS server the load balancer sends it to, all that you need is a reply saying "Yes, in general, sending UDP to my IP on this port is fine with me." You don't need to send it any other application-level data, and frankly the load balancer itself could send that static reply. So you don't care what application server it's sent to.

And once you have that permission, you never need to make an HTTPS connection again.

What you do care is that your actual application traffic, such as your login session, and your UDP traffic have some way of being associated with each other, but you have that problem regardless of how the client (whether it's a browser client or a normal desktop/mobile app) gets permission to send UDP.

As an example, the user could visit example.com, load some HTML and JS, send a request to login.example.com, get a session key, send a single HTTPS request to data.example.com exactly once, and then send UDP to data.example.com protected by that session key. You never send HTTPS to data.example.com again; from this point onwards you only send UDP. Coordination between your HTTPS login server and your UDP data server is no different in this model from the native app model.