fix: tolerate the extra trailing summary models append for the next-turn anchor

[SApplefeld]

Problem

buildXmlTemplate ends the compaction template with a trailing <user> block that anchors where summarization stops. Summarizer models regularly "complete" that anchor with one extra, unrequested <assistant> block. parseSummaries validates by counting <assistant> blocks, so the otherwise-correct response is rejected ("Expected 7 summaries, received 8") and the compaction aborts.

Observed on the Claude Code plugin: with Haiku 4.5 as the summarizer, 3 of 3 attempts on a ~380-row transcript failed (this shape plus two other malformed-output shapes); with Sonnet 5, one occurrence of the +1 shape. Both plugins share the parsing logic, so both are affected.

Fix

• parseSummaries now pairs each echoed <user> block with the <assistant> block that follows it and takes exactly the first expectedCount pairs. The extra trailing block is ignored; a true miss or malformed structure still throws.
• The template marks the trailing next-turn <user> as not-to-be-summarized, reducing the extra block at the source.

Verification

• Claude Code side: the same transcript that reproducibly failed with "Expected 7, received 8" compacts cleanly with the patched parsing (failure observed first, then the fix, then green). Tested via a locally adapted copy of the plugin engine; the two changed functions are identical to this diff.
• OpenCode side: the same mechanical change; tsc --noEmit, eslint, and prettier all pass.

One environment note in passing: the .githooks/pre-commit npx invocations cannot resolve bun-installed binaries on Windows (bun's store has no npm-visible bin entries there), so the hook fails closed for Windows contributors even on a clean tree. Happy to file that separately if useful.