So there are currently more than 30,000 invalid terms in Wikidata, mostly in als, es-formal, no and simple. Doing cleanup again and again is pointless.

It might have to do something with the fact that the tag name školní contains special characters or that it is unused.

There is an abuse filter which tags these changes. It happens every day. It may be more useful when constraints are checked before saving.

Excuse my typo, fixed in description:

Not sure. I'm now quite surprised to see DataSite.editSource in the traceback, given that all new claims can now be created with references via DataSite.addClaim.

Tracked this down. The cause is both rPWBC80e00af9e1139b16842535163f8656a5cea9737d and quite permissive implementation of pywikibot.Claim. Applies to T224283 as well.

that breaks the wikitext parsing in JavaScript

https://cs.wikipedia.org/w/index.php?title=Wikipedie:Pot%C5%99ebuji_pomoc&diff=prev&oldid=17265167&diffmode=source

It tries to edit Archiv1 page...

Niether can I:

Could you try a bit of artificial "sleep" time after the first API call in the gadget, to rule out that it is or is not the timing issue?

In my opinion, this doesn't have to be high priority. WikibasePage is documented with:
There should be no need to instantiate this directly.
Class extensions seem not to have this problem.

Even that doesn't seem necessary to me, the list is already available on every file page.

GlobalUsage was made for this: https://commons.wikimedia.org/wiki/Special:GlobalUsage/De-Luftballons.ogg.

No change has been made yet, it's likely this will happen again and again.
Not sure what those links justify.

Finally, I captured the sever response (and then even one more time):

I have a similar problem: T217512: Merging items sometimes saves a null edit.