Which Portage settings actually prevent a locally built binpkg from being installed on a production host with mismatched USE flags?

I maintain a Gentoo build host that produces binary packages for a small fleet of production servers. The goal is reproducible deployment: a package emerged locally should either install cleanly in production or be rejected with a clear mismatch, never silently installed with different dependency assumptions.

The uncertainty is around how much Portage actually enforces at binpkg install time. My understanding is that a binpkg embeds the USE flags, CFLAGS, and CPU_FLAGS_X86 of the build machine, and that --binpkg-respect-use influences whether a binpkg is accepted when the local configuration disagrees — but it is unclear to me whether this check covers the full dependency graph or only the top‑level package, and whether profile differences (desktop vs. server) between build and production hosts are detected at all. The research I have suggests mismatch detection is not enforced by default, and that behavior differs between Portage 3.0 and 3.1, which I have not verified against a specific version.

Assume a recent stable Portage 3.0.x and matching glibc on both sides.

1. Does --binpkg-respect-use reject a binpkg when the production host’s profile or package.use would produce a different dependency set, or only when the package’s own USE flags differ?

2. Is there any supported mechanism to pin or validate CPU_FLAGS_X86 at binpkg install time, or must that be handled outside Portage?

3. Which files under /etc/portage must be byte‑identical between build and production hosts for emerge --usepkgonly to be deterministic?