fix(ssr): apply ssr props to the the fallback vnode-based branch in ssr

[edison1105]

close #6123

[netlify]

❌ Deploy Preview for vuejs-coverage failed.

Name	Link
🔨 Latest commit	4e22e8f
🔍 Latest deploy log	https://app.netlify.com/sites/vuejs-coverage/deploys/6387fca01eed1300088551ae

[edison1105]

this change ensure initDirectivesForSSR() is called in test.

[github-actions]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	98.8 kB	37.4 kB	33.7 kB
vue.global.prod.js	156 kB	57.2 kB	50.8 kB

Usages

Name	Size	Gzip	Brotli
createApp	54.2 kB	21 kB	19.1 kB
createSSRApp	58.2 kB	22.6 kB	20.7 kB
defineCustomElement	58.8 kB	22.5 kB	20.5 kB
overall	67.8 kB	26 kB	23.6 kB

[edison1105]

/ecosystem-ci run

[vue-bot]

📝 Ran ecosystem CI: Open

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

[skirtles-code]

This change looks good to me.

A couple of observations:

1. The test is based on the original issue, which makes it look a bit more complicated than it needs to be. The slot and recursion aren't really necessary to hit the problem. Just a parent template like <component is="div"><one v-show="false" /></component> is enough, with a child of <div />. It took me a while to understand what was going on because of the extra complexity in the test case.
2. The code is modifying the vnode, with vnode.props =. I'm not sure whether this is potentially a problem. I couldn't find anywhere else in this section of the code that modifies the original VNode like this, though that may just be a coincidence. Maybe there could be a problem if the VNode is reused somehow, or if some other code is expecting to access the unaltered props? Not sure what that would look like in practice, so it may be a non-issue.