Fix </body> hold-buffer scan to use parser context; make nextjs post-processor streaming-safe

[aram356]

Description

From the 2026-07-05 performance & architecture review (P0 finding 4).

The </body> hold buffer does a raw-byte search for </body (publisher.rs:914-966). The literal appearing inside inline JSON/JS (Next.js __next_f payloads, serialized editor content) triggers the hold early, converting the tail-only hold into a near-full-page hold.

Separately, registering any HTML post-processor (currently only nextjs) buffers the whole document (html_processor.rs:59-148). Next.js publishers are a primary SSAT target and currently get the worst of both.

Fix

• Derive the hold from lol_html's parser context instead of raw bytes.
• Make the nextjs post-processor streaming-safe, or explicitly document that combination as buffered mode.

Effort / expected effect

• Effort: Medium
• Expected effect: Removes near-full-page holds on the primary target CMS.

Sequencing item 4 of 10.