We could use https://github.com/twosigma/libvirtcpuid, seems it's commonly used in tandem with CRIU.
Looks like the gitlab runner currently is not able to use CPUID faulting ([pipeline #45703](https://gitlab.winehq.org/bernhardu/wine/-/pipelines/45703)), maybe because of the CPU being an AMD one. It looks like support for it may get available for AMD CPUs in the next kernel releases (https://www.phoronix.com/news/AMD-CPUID-Faulting-Linux-6.17).
IMHO this option is confusing to users, since this envvar only affects the CPUID as viewed by Wine, not by the program or any of our Unix-side dependencies (e.g., glibc / gstreamer / ...) that may invoke CPUID directly.
It's reasonable to expect that some users find that the envvar works around their issue, share their "fixes," and we'd get a bug reports from a bunch of confused users that the envvar doesn't actually "override the CPUID."
Also, this seems quite easy to bitrot: we would have to ensure that _all_ places that call CPUID directly stay up to date. Otherwise the CPUID view would be inconsistent across callsites—debugging that doesn't sound straightforward.
As said, this is not expected to fix anything when users add it. It would be more the other way around: The user reports an unexplainable bug, the developer queries the cpuid environment from the user, and may be able to reproduce the issue with his own more feature-rich CPU.
Or make such regression early visible before or after it got merged.