feat(search): cut result excerpts around the match

[bits-bytes-nn]

Search matched on the full body but showed a fixed excerpt of the first 40
words — and a search term is almost never in the first 40 words.

Measured against the live index before the change:

query	posts matched	matched only past char 300
어텐션	19	19
트랜스포머	19	18
GRPO	7	7
ontology	3	3

So for a realistic Korean query, essentially every result showed prose with no
visible match and nothing highlighted. Correct results looked like wrong ones.

What changed

The excerpt is cut around the match. Done in templateMiddleware, a
simple-jekyll-search hook called once per {placeholder} per result: it receives
the whole field value and returns what to render, so the full body reaches the JS
and only the window reaches the DOM. No second fetch, no body in the markup.

• Multi-word queries try the window at each match and keep whichever covers
  the most distinct query words. Centring on the first match alone gave "vibe
  coding" a window holding only a far-off coding; it now shows both.
• Word-boundary snapping is capped at 12 characters. Korean has no inter-word
  spaces, so an unbounded search for one runs past the match and swallows the
  window — the same trap as the truncation floor in post_description.rb. The cap
  degrades it to a clean character cut.
• Escaping is ours. The library inserts middleware output as HTML, so the text
  is escaped here and the only tags introduced are the <mark>s. Verified with a
  > query.

The index is now real plain text (plain_text, new _plugins/search_index.rb).
strip_html | strip_newlines had two defects that both reached the reader:

• Entities stayed encoded — 29 of 35 posts carried them, so the card printed
  "음료 > 탄산음료" verbatim.
• Tags were removed with nothing left behind, so <p>끝</p><p>시작</p> indexed as
  끝시작, one token matching neither word.

Order is load-bearing and tested: strip tags before decoding entities, or a
post quoting <script> gets a real element that the strip then deletes
along with the author's words. Inline tags unwrap with no space so <em>강조</em>된
stays one word.

Also: the snippet field is gone (84 KB smaller index); the status line says
"Showing the first 10 matches." instead of reporting a total the library cannot
know, since it stops scanning at limit; and .result-tags was missing from the
dark-mode overrides, sitting at 4.2:1 — below AA — so it moves to $fg-muted
(6.2:1).

Retired along the way: the post-render highlight() pass, its data-original
bookkeeping, escapeRegExp, and the 120 ms debounce that existed to sequence
them. Highlighting happens during render now.

Verification

Driven in a real browser, not reasoned about: a driver script was appended to the
throwaway build so Chrome types into the actual /search/ page against the actual
index. Every result for 어텐션, GRPO, >, attention transformer, Pixtral and
vibe coding came back with at least one <mark> inside a match-centred excerpt.
Checked in both themes.

Gates: 93 tests / 157 assertions, clean build, html-proofer successful, all 16
validate-site checks passed.

Still open, now documented precisely in §9

• No relevance ranking. The library scans in site.posts order and stops at
  limit, so results are newest-first and a title match does not outrank a
  passing mention. A sort hook can't fix it — sorting happens after truncation.
  Doing it properly means owning the match/sort/slice loop, at which point the
  library (used only for fetch, substring match and template fill) should go.
• Math shows raw in excerpts. The index is flattened rendered HTML, so MathJax
  delimiters survive as \(O(L^2)\) and appear when the window lands on one.
  Stripping math from the index would fix it at the cost of making characters
  inside formulas unsearchable — left alone rather than decided unilaterally.