fix(runtime-core): prioritize using the provides from currentApp in nested createApp

[edison1105]

close #11488

[github-actions]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	90.1 kB (+10 B)	34.5 kB (+7 B)	31.1 kB (-3 B)
vue.global.prod.js	147 kB (+10 B)	54 kB (+7 B)	48.1 kB (+16 B)

Usages

Name	Size	Gzip	Brotli
createApp	49.7 kB (+10 B)	19.5 kB (+5 B)	17.8 kB (+4 B)
createSSRApp	53.2 kB (+10 B)	21 kB (+6 B)	19.1 kB (+1 B)
defineCustomElement	51.9 kB (+10 B)	20.2 kB (+5 B)	18.5 kB (+5 B)
overall	63.1 kB (+10 B)	24.5 kB (+7 B)	22.3 kB (+6 B)

[edison1105]

/ecosystem-ci run

[vue-bot]

📝 Ran ecosystem CI: Open

suite	result	latest scheduled
language-tools	❌ failure	❌ failure
nuxt	❌ failure	❌ failure
pinia	✅ success	✅ success
primevue	✅ success	✅ success
quasar	✅ success	✅ success
radix-vue	✅ success	✅ success
router	✅ success	✅ success
test-utils	✅ success	✅ success
vant	✅ success	✅ success
vite-plugin-vue	✅ success	✅ success
vitepress	✅ success	✅ success
vue-i18n	✅ success	✅ success
vue-macros	❌ failure	❌ failure
vuetify	✅ success	✅ success
vueuse	✅ success	✅ success
vue-simple-compiler	✅ success	✅ success

[Bertie2011]

Are we certain that currentApp is null/undefined outside runWithContext?

Also, could be simplified to:

const provides = currentApp
      ? currentApp._context.provides
      : instance
        ? instance.parent == null
          ? instance.vnode.appContext?.provides
          : instance.parent.provides
        : undefined

Or even

const provides = currentApp
      ? currentApp._context.provides
      : instance?.parent == null
          ? instance?.vnode.appContext?.provides
          : instance.parent.provides

[edison1105]

@Bertie2011

Are we certain that currentApp is null/undefined outside runWithContext?

I think so.

we avoid using optional chaining at runtime. see #4882 (comment)