Bump stylis to ^4.3.4

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
stylis	^4.3.2 -> ^4.3.4

---

Release Notes

thysultan/stylis.js (stylis)

v4.3.4

Compare Source

v4.3.3

Compare Source

---

Configuration

📅 Schedule: Branch creation - "on sunday before 6:00am" in timezone UTC, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[mui-bot]

Deploy preview: https://deploy-preview-14323--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against 0432c1e

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[LukasTy]

@JCQuintas on such core dependencies, especially ones that are coming from Core I tend to wait until they bump it first. 🙈
mui/material-ui#37791

[JCQuintas]

🤔 I think I mistook this one for another. I was trying to figure out which ones come from core by seeing if they are duplicated in the package lock, which this one is, but it skipped me for some reason 😅

[JCQuintas]

On another note, should we handle this differently? Like, I know we probably use this directly in our scripts, but we could define them as a required peerDep and set it to an exact version in the core/package.json, which probably would mean we always update to the correct one, and we wouldn't need to check 🤔

[LukasTy]

On another note, should we handle this differently? Like, I know we probably use this directly in our scripts, but we could define them as a required peerDep and set it to an exact version in the core/package.json, which probably would mean we always update to the correct one, and we wouldn't need to check 🤔

Once everything in common for docs to function is moved to @mui/docs we would get a more clear separation of what is a peer dependency and what is coming transitively from @mui/docs.
But this case is slightly different, because we use stylis explicitly in a few of our demos. 🙈
I think there is no problem here, but I would have still waited for other dependencies to catch up and Core to merge it first, given that this dependency is kind of integral part of the docs.