Issue Summary

When a heading's ADF content array contains more than one child node, e.g. a text node followed by an inlineExtension node (any macro represented as an inline extension, such as the Anchor macro), the "Copy link to heading" hover feature incorrectly builds its URL fragment by concatenating a slugified version of the text with the literal, unslugified placeholder string [inlineExtension] for the non-text child, instead of ignoring/omitting it. The resulting link is broken and does not navigate to the heading.

Steps to Reproduce

1. Using the Content REST API, create or update a page whose body.storage contains:

<h2>Test Heading<ac:structured-macro ac:name="anchor" ac:schema-version="1">
  <ac:parameter ac:name="">Test Heading</ac:parameter>
</ac:structured-macro></h2>

(Confluence Data Center produces this shape for the common "anchor in heading" pattern. The Cloud storage API accepts it, though the Cloud editor can't author it.)
2. Open the page in Confluence Cloud page view.
3. Hover over the heading "Test Heading".
4. Click the "Copy link to heading" icon.
5. Paste the clipboard contents.

Expected Results
https://<site>/wiki/.../<page>#Test-Heading

Actual Results
https://<site>/wiki/.../<page>#Test-Heading%5BinlineExtension%5D (decoded: #Test-Heading[inlineExtension])

Root cause hypothesis
The ADF→plain-text flattening utility used by the heading-link slug builder has no handler for inlineExtension nodes and falls back to emitting the node-type name as a literal bracketed placeholder. This is the same defect class as two other closed/known issues affecting different features and different macro types entirely (ruling out anchor-macro-specificity)

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available