The public_name cloudflare-ech.com comes from DNS.
$ echo AEX+DQBB8gAgACDCIaU3P6vz668J2oRRZtptSEwH+1IX8/3TOArEx0tRLAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= | base64 -d | xxd
00000000: 0045 fe0d 0041 f200 2000 20c2 21a5 373f .E...A.. . .!.7?
00000010: abf3 ebaf 09da 8451 66da 6d48 4c07 fb52 .......Qf.mHL..R
00000020: 17f3 fdd3 380a c4c7 4b51 2c00 0400 0100 ....8...KQ,.....
00000030: 0100 1263 6c6f 7564 666c 6172 652d 6563 ...cloudflare-ec
00000040: 682e 636f 6d00 00 h.com..
https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-05.html#section-3
https://www.ietf.org/archive/id/draft-ietf-tls-esni-22.html#section-4
Different servers may use different public_names. Cloudflare servers will use cloudflare-ech.com, other web hosts will use a different name. The information an observer can get from observing public_name should be roughly the same as what it can get from observing the destination IP address.
It may not be as easy as you think. I have not looked at how things are actually implemented, but TLS clients that support ECH are supposed to send an ECH TLS extension even when they are not using ECH. This is called ECH GREASE. It’s not quite like the situation with ESNI in 2020, when only connections that used ESNI sent the ESNI TLS extension.
6.2.GREASE ECH
If the client attempts to connect to a server and does not have an ECHConfig structure available for the server, it SHOULD send a GREASE [RFC8701] “encrypted_client_hello” extension in the first ClientHello as follows: