fix(memory): word/sentence-boundary aware fact truncation

[kareem-jalal]

Bug

src/lib/memory/extraction.ts truncates extracted memory facts with raw
character-offset slicing and no boundary awareness:

• sanitizeMatch() did raw.trim().replace(/\s+/g, ' ').slice(0, MAX_FACT_LENGTH)
  — a hard cut that can land mid-word.
• capExtractionText() did text.slice(-MAX_EXTRACTION_TEXT_LENGTH) on the
  front edge when input exceeds MAX_EXTRACTION_TEXT_LENGTH (64KB) — same
  problem, opposite edge.

These facts later get injected into LLM context as <system-reminder>
memory blocks, so a mid-word/mid-clause cut produces garbled fragments
(e.g. text starting with a stray closing parenthesis, or ending with no
punctuation and a half word).

Fix

• sanitizeMatch() now backs the cut index off to the nearest clean
  boundary within a lookback window: prefers a sentence-ending mark
  (./!/?) so the fact reads as a complete clause, falls back to a
  plain whitespace/word boundary, and only falls back to the original hard
  cut when no boundary exists in the window (e.g. one long unbroken run of
  characters).
• capExtractionText() applies the equivalent boundary-aware trim on the
  front edge of the kept tail (extends the cut forward to the next
  whitespace boundary rather than slicing mid-word).

This mirrors the boundary-aware truncation already used by
open-sse/services/compression/lite.ts (issue #8169) for tool-result
truncation, so the codebase now has one consistent pattern for this class
of problem.

Testing

• New: tests/unit/memory-extraction-boundary-truncation.test.ts — covers
  a long match cut at a word boundary, a match cut preferentially at
  sentence-ending punctuation, short strings passing through untouched,
  the no-boundary-in-window fallback, and capExtractionText's
  boundary-aware tail behavior (both under and over the 64KB cap).
• Ran existing tests/unit/memory-extraction.test.ts alongside the new
  file — all 28 tests pass, no regressions:

  ℹ tests 28
  ℹ pass 28
  ℹ fail 0
  

• npx tsc --noEmit -p tsconfig.json — no new type errors introduced by
  this change.

No unrelated files were touched.

[diegosouzapw]

Nice fix — matching the same boundary-lookback pattern the repo already uses for #8169
(compressToolResults) is a good consistency call, and the sentence-punctuation-first /
word-boundary-fallback / original-cut-as-last-resort chain reads cleanly. Please add a
changelog fragment under changelog.d/fixes/ before merge.

[diegosouzapw]

Thanks @LeMonBLOCK — merging via the release merge-train. Validated in local merge-train (merge-train-20260918-120911-suite.log) on the devbox @ train tip 8c305709478b7052fb981a75852bbf88fe3a959d with the sibling PRs of this batch: typecheck:core, file-size, complexity, cognitive-complexity, changelog-integrity green; changed-area node:test 310/311 (the single red, hard-lease inventory, reproduces on the pure release tip) + vitest green (fast parity mode — full suite ran today on the tip via the base-red and 3b trains). Merged --admin per merge-gates §4/§7.