Build validation limits with mixed @remix-run/* dependencies

When @remix-run/* dependencies are upgraded across inconsistent versions, the production build may succeed while runtime hydration fails. This question examines the extent to which Remix's documented build command validates server/client boundary integrity under such conditions. The build command checks route module syntax and server/client exports, but its coverage of dependency-version drift remains unclear, especially when the legacy remix package migrates to scoped @remix-run/* packages across a team's lockfile. Package manager differences (npm, pnpm, Yarn) and lockfile strategy further influence whether incompatible versions surface during the build step or only at deployment. Additionally, hydration mismatches are known to appear predominantly in production builds, meaning a locally successful build does not guarantee deployment safety.

Given these constraints, it is uncertain whether the build command alone serves as a sufficient safety net after a failed upgrade, or if supplementary checks are required to detect server/client version drift before deployment. The interaction between major-version migration steps and the build validator's scope has not been explicitly documented for all supported release lines.

What degree of dependency-version inconsistency can the build command tolerate before route modules or server/client boundaries are flagged? Does the validator inspect transitive @remix-run/* version alignment, or only top-level package resolutions? Are there configuration flags or experimental modes that extend validation to lockfile-level dependency graphs?