Pasting is keeping background-color even with `doNotAdjustEditorColor: true

Describe the bug

Hello,

something is behaving weirdly and I'm pretty sure this was not the case at least a few months ago 🤔
a simple copy / paste of a word from and to the editor is inlining a background-color attribute, even if it's white on an already-white editor background (so the user has no way to detect this).
The consequence is pretty dramatic in a mail client usage because the output of the HTML sent will show the pasted words on white, while the rest of the text will be shown on whatever background color the recipient's mail client is set with.

I suspected the background-color style attribute added on the editor contentDiv, which is not set if using doNotAdjustEditorColor: true contructor option, but that doesn't change anything. I'm still convinced it's something that was done in order to correctly render in darkMode.

To Reproduce
Steps to reproduce the behavior:

1. Go to Rooster Demo (or Outlook)
2. type anything
3. select a word -> copy
4. paste it in the same draft
5. inspect that pasted word in the devtools : it has a background-color definition, whereas the copied word has not.

Expected behavior
Pasted text should not declare a background-color style attribute as long as it is the same color than its computedStyle

Screenshots
If applicable, add screenshots to help explain your problem.

Device Information

• OS: [e.g. iOS] : macOS
• Browser [e.g. chrome, safari] : chrome
• Version [e.g. 22] : current demo 8.51.0 — at least since 8.44.1

Additional context
Add any other context about the problem here.

Start by reproducing the copy-and-paste behavior in the Rooster Demo or Outlook with doNotAdjustEditorColor: true, then inspect the pasted word in browser developer tools. Done means pasted text does not declare a background-color style when that color matches its computed editor background.