We add our own CSP by using a responseProcessor, and it works as expected everywhere except in edit mode. In edit mode I can see in our log that the responseProcessor is doing the same as in every other mode (and adds the CSP as expected), but we are still stuck with the default CSP from Enonic. Also, for edit mode, adding site.preview.contentSecurityPolicy = to XP_HOME/config/com.enonic.xp.admin.cfg does not make any difference, we still get the default CSP from Enonic.
The reason it works differently in edit mode is that Page Editor is using an iframe to display the content, so there we have to use a meta tag to inject the CSP, rather that using a header like in preview.
If you are injecting your own CSP using responseProcessor rather than configuring CSP via config file, I suggest you turn off CSP completely (this will turn it off in the editor as well) and keep on using responseProcessor to inject the CSP header.
There are two different docs on CSP - one, that you mentioned, for XP (that describes config for inline and preview modes) and another for Content Studio (which is for the Content Studio itself and page editor).
It seems like that the CSP configured in the Security Header application fires when browsing in the Content Studio. However, Widgets in Content Studio (not edit mode) is ignored by the Security Header CSP.