preset-env useBuiltIns and corejs: pinning the installed core-js major for compiled files

In the @babel/core 7.x line, @babel/preset-env can inject polyfills through useBuiltIns, but the corejs option must name a version that matches the core-js package actually installed. With useBuiltIns: 'usage', Babel rewrites each file it compiles to import only the core-js modules that file's syntax requires; with 'entry', it expands a single core-js/stable import. Babel errors when useBuiltIns is set without a corejs version, yet a version string that does not match the installed package can still produce resolution failures or target the wrong polyfill set.

The unresolved policy decision is where polyfills belong: preset-env's global injection with core-js as a runtime dependency, or transform-runtime's per-module imports via @babel/runtime-corejs3, which avoids global pollution but adds a heavier runtime package. A related boundary is that 'usage' only patches files Babel compiles, leaving untranspiled node_modules unpatched.

Which placement fits a library versus an application? How should the corejs option be kept in step with the installed core-js major? Does debug: true reveal enough to confirm the resolved targets and core-js version?