I've narrowed it down to the mismatched font style inside the header. This is the minimal code where I can reproduce it:

== test ==

=== '''test''' ===

test

=== '''test''' test''' ===

test

=== test ===

test

Note the mismatched weight on the third header.

which generates the following html:

<h2><span class="mw-headline" id="test">test</span></h2>
<h3><span class="mw-headline" id="test_2"><b>test</b></span></h3>
<p>test
</p>
<h3><span class="mw-headline" id="test_test"><b>test</b> test<b></b></span><b></b></h3>
<p>test
</p>
<h3><span class="mw-headline" id="test_3">test</span></h3>
<p>test
</p>

It generates the same HTML on the old vector, but probably due to differences on context, the other skins seem to be more resilient to bad formatting.
I will fix this on the wiki article, but leaving the ticket open, as this edge cases could be useful to improve the parser.

The bad formatting can still be seen on: https://es.wikipedia.org/w/index.php?title=Trilog%C3%ADa_de_Ant-Man&oldid=145686652&useskin=vector-2022 I will update the description link.

Or copying and pasting on a test page the above wikicode, so one can work with a smaller example.

Thanks for the bug report and clear replication steps. I'm a bit concerned the parser allows valid markup. Olga: We should add this to the list of things to talk to the parser team about.

These errors are flagged as https://www.mediawiki.org/wiki/Help:Lint_errors/unclosed-quotes-in-heading on all wikis and editors should simply fix those pages.

With Parsoid, this won't be an issue. But, we can see what we could do to make this more robust in the interim with the legacy parser output that doesn't have a perf. impact on all pages.

This seems very much related to T308398.

If we don't want to ask editors to fix the lints, you will have to "tidy" the TOC HTML in the vector skin code OR we could do this for all skins before setting the TOC HTML OR w tidy the heading HTML as we encounter them.

It will add a pageload cost to all pages in all those scenarios, but, that can be quantified.

This is unlikely to be an issue with Parsoid since we are already dealing with DOM and DOM fragments and can deal with it on a per-heading basis.

Short term solution is probably to run Remex to tidy the TOC HTML. That imposes a pageload cost, but TOCHTML is small, and the cost will eventually go away when the longer term solution is implemented.

Longer term solution is to build the TOC from the section data (T293513) and if we do that with a DOM API instead of via string concatenation then the balance problem should take care of itself. (Parsoid ought never to generate section data with unbalanced tags.)

(I believe the headings are already sanitized to some degree; might be worth doing this consistent with how DISPLAYTITLE is sanitized (aka use Sanitizer::removeSomeTags).)

@ovasileva Parser team is not planning to fix this as there focus is switching to Parsoid (where this problem doesn't exist). Web team will need to reach out to the parser team to prioritize this work with we are not happy to wait for Parsoid to fix this.