Chakra UI v3 Provider API boundary for incremental migration

The objective is to migrate a single Chakra UI component from v2 to v3 while the remainder of the application continues to run on v2, ensuring no visual downtime, consistent theming across the boundary, and no unplanned bundle-size increase.

Chakra UI v3 replaces the Emotion-based style engine with a recipe and slot-recipe system (defineConfig, defineRecipe), meaning custom theme tokens and component style overrides cannot be copied directly from the v2 theme object. The v3 Provider, built on createSystem/defaultSystem, must be scoped to a distinct subtree to avoid nesting conflicts with the v2 ChakraProvider, yet the exact mapping of v2 theme values to v3 recipe slots remains version-sensitive across minor releases. Additionally, color-mode handling differs between v2 ColorModeScript and v3 ColorModeProvider, risking theming flashes during overlap, and the official codemod may not cover all style overrides in codebases that rely on extended theme properties.

Which v3 recipe slot parameters correspond to the v2 theme token values for typography and spacing when the theme has been extended with custom properties? How does the v3 ColorModeProvider resolve inherited mode preferences when a v2 ColorModeScript instance remains active in the ancestor component tree? At what component nesting depth does CSS specificity conflict become probable between v2 Emotion-generated rules and v3 recipe-generated rules, and what mitigation strategies does the migration guide recommend for such seams?