fix(elements): dedupe in-flight code block tokenization

[ephraimduncan]

Problem

The first render of any uncached code/language pair launches two Shiki tokenization jobs for the same input. CodeBlockContent calls highlightCode from two paths in the same render cycle:

1. the render-time memo (highlightCode(code, language) ?? rawTokens)
2. the passive effect (highlightCode(code, language, callback))

Before the first job can populate tokensCache, the effect's cache miss starts a second getHighlighter(...).then(codeToTokens). Both execute codeToTokens; the later one overwrites the same cache entry. During streaming, where every chunk is a new uncached string, this doubles the expensive part of the hot path.

Fix

• Track in-flight work in a pendingHighlights set keyed by the token cache key. A cache miss with a pending job subscribes the callback and returns null instead of starting duplicate tokenization. The set is cleared on both success and failure so a rejected highlight permits a later retry.
• Found while verifying the retry path: getHighlighter cached rejected createHighlighter promises per language forever, making a language permanently unhighlightable after one transient failure. Rejected promises are now evicted from highlighterCache.

Immediate raw-token rendering while Shiki loads is unchanged, as is the subscriber fan-out.

Verification

Regression test (describe("highlightCode") in code-block.test.tsx, shiki mocked at the module boundary with a counting codeToTokens spy):

• one tokenization per uncached first mount (fails with "called 2 times" on pre-fix code)
• two concurrent subscribers receive the same in-flight result from one job
• a rejected highlight permits a later retry (fails on pre-fix code: rejected highlighter promise was cached forever)

All 3 tests fail against the pre-fix source and pass with the fix; existing code-block and snippet suites pass; ultracite check clean on touched files.

[vercel]

@ephraimduncan is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.