HTML inside breadcrumb items rendered as text in 2.0.10

oof, thanks for the report. We'll be looking into fixing this soon.

I added a failing test in the issue branch.

I will work on a fix now. I am pressed for time today. We'll see how it goes.

Sorry, just ran out of time and couldn't figure it out yet.

I dug into the regression and found the root cause. Commit 4307e2d (which fixed #3568508) bundled two unrelated changes into formatTitle():

1. The actual fix for #3568508: adding the is_string($title) case so plain strings also go through Html::decodeEntities() (previously only MarkupInterface objects did, causing double/triple-encoded entities on alternate title fields).
2. An unrelated, unintended change: for the MarkupInterface case, it switched from stripping all HTML tags (strip_tags()) to preserving an allowed-tags whitelist (Xss::filter()).

Change #2 is what causes this issue. Core wraps %placeholder values in t() as <em class="placeholder">...</em> — this is exactly the title Drupal generates for routes like the taxonomy vocabulary edit form. Before 2.0.10, strip_tags() removed that markup, leaving plain "Edit Tags". Since 2.0.10, Xss::filter() preserves the <em> tag in the string — but nothing downstream (the Capitalizator's word-splitting, or the final new Link($title, $url) construction) treats the result as safe markup. So the raw tag leaks into the rendered breadcrumb as literal text.

I reproduced this exactly using the failing test already on this branch: instead of Edit Tags, the actual output was Edit <em Class="placeholder">Tags</em> — note even the class attribute got capitalized to Class, because the Capitalizator's word-splitting logic treated the tag fragment as a regular word and applied ucfirst() to it. That confirms nothing in the pipeline is prepared to handle preserved HTML.

Fix: reverted just that one branch back to strip_tags(Html::decodeEntities($title)), keeping the real #3568508 fix (entity decoding for plain strings) intact. The #markup render-array branch was left untouched since it isn't part of this regression.

Validated on a real Drupal 11 install (not just code review):

• The existing failing test (EasyBreadcrumbTermHierarchyTest) now passes (11 assertions).
• The #3568508 regression test (EasyBreadcrumbAlternateTitleFieldTest) still passes (13 assertions) — confirming this fix doesn't reintroduce that bug.
• To be sure the test actually catches the bug, I temporarily reverted just the fix and reran: it failed with the exact same error (Edit <em Class="placeholder">Tags</em>). Restoring the fix made it pass again.

This looks correct and ready for review.

✅ Tested and works — MR !235. Reproduced the escaped markup on the taxonomy admin paths in Claro, confirmed the fix restores Edit Tags, checked that the added test really fails without it and that the #3568508 entity-decoding fix is not reintroduced as a bug. The pipeline was red on two lint issues, so I pushed those fixes to the branch as well; it is green now.

I'm going to split the test into two so that the new assertions are not lumped in with the TERM_HEIRARCHY test, something I should have done in the first commit in this branch but ran out of time.

Thanks justcaldwell, andres alvarez, csakiistvan, and greg boggs (behind the scenes).