core-js/stable global built-in patching before application code loads

Goal

Determine whether a small Node.js or bundler-based application can migrate to core-js 3.x without downtime while importing core-js/stable, or whether core-js/pure is required to avoid changing native built-in behavior.

Constraints and uncertainty

core-js 3.x's core-js/stable entry point patches native globals such as Promise, Array, and String at import time. In a long-running process those patches persist for the process lifetime and cannot be unloaded without a restart, which complicates zero-downtime rollback. Code that runs before, during, or after migration, plus third-party libraries loaded later in the same bundle, may observe different built-in identity or feature-detection results. The exact core-js major version and current import paths in the codebase are not confirmed, and bundler tree-shaking behavior for pure entry points is unverified.

Does importing core-js/stable before application code alter native methods in a way that breaks feature detection or third-party code? Is core-js/pure with explicit imports sufficient for the application's polyfill needs without global mutation? Which staging checks can distinguish safe global patching from unacceptable built-in behavior changes?