fix(extract): treat any non-whitespace-flanked period as non-boundary

[philluiz2323]

What changed

extract.py's _SEGMENT_RE now treats any period flanked by non-whitespace
on both sides as a non-boundary, instead of only one flanked by digits.

Why

The old lookaround, (?<=\d)\.(?=\d), correctly kept decimal/version
numbers intact ("6.8.3") but did nothing for the far more common case of
periods inside file paths (src/vouch/cli.py), module/line references
(cli.py:2550), or domains (github.com) — every one of those still
split the sentence. segment_source has no coherence check afterward,
only a minimum-length and letter-ratio filter, so the resulting
mid-sentence shards survived and got filed via extract_receipt_claims
→ propose_quoted_claim, which auto-approves anything that verifies as
a byte-exact quote of the source (review.auto_approve_on_receipt
defaults to True).

Confirmed with a repro: ingesting "the parser bug lives in
src/vouch/cli.py:2550 near the top. see the changelog at
github.com/vouchdev/vouch/blob/main/CHANGELOG.md for details." produced
four durably-approved claims, two of them nonsensical fragments
("see the changelog at github.", "py:2550 near the top.").

Fixes #702

What might break

Nothing for users with an existing .vouch/ directory — no on-disk
shape, kb.* method, or object model change. Behaviorally: sentences
containing a file path, module reference, or domain now stay intact
instead of fracturing, which is strictly the intended, documented
behavior for decimals extended to a broader (and more common) class of
non-boundary periods. No legitimate sentence-ending period changes
behavior, since a true sentence end is followed by whitespace or
end-of-string, which still terminates the segment.

VEP

Not applicable — no object model, kb.* method, on-disk layout, bundle
format, or audit-log shape change. A regex-correctness fix inside the
ingest segmenter.

Related prior work

A related PR, #518 (fix(extract): stop fragment claims and stopword-matched injection), touched adjacent parts of this file but
was closed unmerged with an unresolved CodeRabbit nit (an unrelated
markdown-bullet-prefix gap) and predates select_spans's
density-selection logic added since, so its diff no longer applies. This
PR targets a narrower, independently-verified defect in the current
code — the segmentation regex's digit-only lookaround — unrelated to
what #518 was reviewing.

Tests

• Local make check-equivalent: ruff clean (src + tests); mypy
  clean on extract.py; all 14 tests/test_extract.py cases pass
  (13 pre-existing + 1 new); tests/test_bench.py,
  tests/test_capture_answer.py, tests/test_capture_scope.py, and
  tests/test_health.py (all consume extract.py) pass with one
  pre-existing, unrelated failure
  (test_finalize_supersedes_updated_claims), confirmed present
  identically on test HEAD before this change via git stash
  comparison
• New / changed behaviour has a test —
  test_segment_source_keeps_file_paths_and_urls_intact
• CHANGELOG.md updated under ## [Unreleased]

[plind-junior]

the bug is real and the repro is convincing — "see the changelog at github." reaching decided/ as an auto-approved claim is exactly the failure mode auto_approve_on_receipt makes expensive, because a byte-exact quote of a garbage shard still verifies. no argument that (?<=\d)\.(?=\d) was too narrow.

my concern is that the replacement is very broad in the other direction, and the PR only tests the direction it is trying to fix. (?<=\S)\.(?=\S) says a period is a boundary only when whitespace or end-of-string follows it, so every one of these now merges what used to be two segments:

• a missing space after a full stop — "ship it.Then we deploy." — which is ordinary typing noise in the chat transcripts this segmenter runs on
• a period before a closing quote, paren or bracket — "we agreed (see docs.)", he said "done."
• an ellipsis — "wait... then go"

the result is a longer run, and segment_source's only downstream filters are min length, max length and letter ratio. so an over-merged run either survives as one run-on claim or trips DEFAULT_MAX_CHARS = 320 and is dropped entirely — a fact silently lost rather than fractured. under auto_approve_on_receipt the first outcome is durable without review, same as the bug you are fixing.

concretely: the three new assertions are all "these stay intact", and none is "these still split". worth adding the negative half — a two-sentence string with a missing space after the period, and one ending docs.) — and deciding explicitly which behaviour you want. if merging on a missing space is not acceptable, the narrower rule that still fixes #702 is to exclude whitespace and sentence-case starts, e.g. requiring the following character to be lowercase or a digit: (?<=\S)\.(?=[a-z0-9/]). that keeps cli.py, github.com and 6.8.3 intact while ship it.Then still breaks.

the CHANGELOG wording is accurate about what the regex does, so no issue there.

[github-actions]

diff coverage: n/a — this PR changes no python under src/vouch/, so there is nothing for the gate to measure.