Preserve caller attributes on code block content

[cjs226]

HighlightedTextFragment rebuilds every syntax token from its plain String:

let code = String(content.characters[...])
tokens = [CodeToken(content: code, type: .plain)]
...
var content = AttributedString(token.content)

That discards every attribute the caller's MarkupParser applied to the code block. Any decoration a client adds, such as search highlighting and custom inline styling, is applied correctly at parse time, survives into the AttributedSubstring the code block receives, and is then silently dropped before it reaches the screen.

There is no way to work around it from outside the library. CodeBlockStyleConfiguration exposes only a type-erased label, an indentationLevel, a languageHint, an opaque CodeBlockProxy, and the theme. So a custom CodeBlockStyle cannot recover the text to re-render it, and cannot even detect that a block contains anything of interest.

The change

Walk the original attributed content in parallel with the tokens and slice it, rather than rebuilding each token from its plain string. Theme attributes are still merged on top, so syntax colouring continues to win for the keys it sets (foregroundColor, presentationIntent) while caller attributes survive for the rest.

If the tokenizer's total length ever disagrees with the source, that token falls back to the previous plain-string behaviour, so text can never be lost — only the attributes on that token.

No API change, no behaviour change for callers that don't attach attributes.

How it came up

Adding find-in-text search to an app that renders notes with Textual. Matches inside fenced code blocks were located and highlighted correctly by a custom MarkupParser, then vanished on screen — the highlight renders for one frame before .onChange triggers highlight(tokens:...) and replaces the attributed text wholesale.

Tests

Adds Tests/TextualTests/Internal/Highlighter/HighlightedTextFragmentTests.swift covering:

• a caller attribute survives on code block content
• it survives being split across token boundaries
• text and attributes are unchanged when the caller applies none
• theme token properties still style tokens alongside a caller attribute
• the length-mismatch path still emits the plain token, losing no text

All five fail against the previous plain-string rebuild and pass with the fix.

Also verified in a real macOS 26 app: search highlighting now renders inside fenced code blocks, and syntax colouring in those blocks is unchanged.

Local verification

make test-macos, make test-maccatalyst and make build-demo all pass.

make test-ios has one pre-existing snapshot failure on my machine (TextLayoutCollectionTests.twoParagraphsBidiStructuredTextLayout) — 164 of 165 pass. Running the same suite against a different simulator turns that into four layout snapshot failures, so these look device/OS sensitive rather than related to this change, which touches only code block rendering. Happy to look if CI disagrees.

I could not run the Xcode 16.4 backward-compatibility job (no 16.4 locally), nor tvOS/visionOS (runtimes not installed).