If we're keeping this simple, then I'd say have IP address in subaltnames. Obtaining such certs shouldn't be a problem for CDNs, and possible for others as well (regarding free options: Let's Encrypt doesn't support that, but ZeroSSL does)
You wouldn't even need a cert for an IP address (which is hard to get). You could just resolve the CNAME and A records until you arrive at an address, do a reverse lookup on that address. Then use the resulting "primary" PTR hostname for the encryption certificate. No additional info for an attacker, no new weird RRs, in the best case just one additional DNS query (but SVCB would need that as well).
That means one-site-per-IP, which doesn't work with the way we currently do L3->L5.
One-site-per-IP also ruins much of the point of ESNI, since then anyone who wants to block or track what domain you are visiting can just lookup the domains they’re interested in and match them to IP addresses.
For the most part they can do that anyways, ESNI or ECH are only relevant for big hosters or proxy services.
no, the per-ip key is just the one you would use for ECH, in the encrypted part you can use separate per-vhost certificates as usual
No, this is just a way to verify the Cert for the first handshake, so that one doesn't need to use one with the IP in the sub alt names.
That would require coordination with a certificate authority any time your IP changes, which could be very inconvenient in some cases.
Meanwhile, DNS records already need to be updated if your IP changes anyway, so it is a logical place to put the authenticity information