fix(deriver): word-boundary matching in violatesPrivacy — short People slugs block every hypothesis

[Pfassmeyer]

Symptom

The proactive deriver (--hypothesize) can silently emit zero hypotheses forever. The run log shows healthy clusters that all die at the privacy gate:

clusters: 8
privacy-block: <every single cluster>
dry-run: would emit 0 hypotheses

The failure mode is a clean emitted=0, indistinguishable from "nothing to report" — so nobody notices the loop is dead.

Cause

violatesPrivacy() uses substring matching (norm.includes(...)) against KNOWLEDGE/People slugs. People notes can legitimately have very short slugs (an initial, a nickname — e.g. e.md). A single-letter slug then matches any text containing that letter, so every candidate hypothesis is blocked.

Underscore-separated slugs (Firstname_Lastname.md) are also never matched, because only - is normalized.

Fix

Word-boundary regex matching instead of includes(), with both - and _ separator normalization. The guard's intent is preserved: claims that actually name a person still block.

Text	Slug	Before	After
"Recurring incomplete work pattern…"	e	❌ blocked	✅ passes
"E said she will visit"	e	blocked	✅ still blocked (boundary hit)
"meeting with mary about seo"	mary	blocked	✅ still blocked
"firstname lastname approved"	firstname_lastname	⚠️ passed (underscore never matched)	✅ blocked

Tested against a 12-case matrix (short slugs, underscore slugs, real-name mentions, cluster-name false-positives): every real name still blocks, no cluster name falsely blocks.