So having thought about this, I should be clear how I'm coming at the answer. We already have a pair of questions that address the issue of whether dynamic linking creates derivative works; one for those who think it does, and one for those who think it doesn't. Both note that the question remains unsettled, but I firmly believe that dynamic linking does create derivative works, and the rest of this answer reflects that.
To my mind, one of the key arguments for dynamic linking creating derivatives is that, unless there is a published third-party guide to the API, the only way to discover how to call the library code (either via dynamic linking or at run-time) is to inspect the library code, or to read the (GPLed) project documentation.
If you were to inspect the library code in order to reimplement it from scratch, you would have contaminated yourself such that the reimplementation is likely to be held to be a derivative work; hence the clean-room reimplementation. As I see it, the same applies to anyone inspecting the library code in order to work out how to call it; you are taking its methods and APIs with you following an inspection of the source. As pointed out elsewhere in the SE universe, APIs can be and often are copyrightable; Oracle v. Google turned on a fair-use defence, and (by clean room principles) it's not at all clear one could succeed in one of those after having read all the source code.
So as I see it, you're doing something just as copyright-entangling as dynamic linking, and thus your work has to be GPLv2 also. If you invoke the editor at arms-length, through (eg) fork-and-exec with a simple filename passed between caller and editor, I would hold differently; but you're not, and the fact you're doing it in an interpreted language rather than a compiled one doesn't make me see it differently.
Edit: I also suspect that the CKEditor people see things the same way. They write:
CKEditor 5 is licensed under the terms of GNU General Public License Version 2 or later.
If you are running an Open Source project with an OSS license incompatible with GPL please contact us and we will be happy to support your project with a CKEditor 5 license.
Earlier versions were licensed under multiple terms, one of which was LGPLv2.1+. This option has gone, for version 5; clearly they feel that
there are uses that LGPL permitted that they no longer wish to permit, and your proposed usage seems to me to be exactly one such.