feat: lessons as a typed artifact with follow-through tracking

[dripsmvcp]

Summary

ClaimType already carried workflow and warning — the vocabulary of a procedural rule. what was missing is the loop that makes such a rule earn its place: nothing recorded whether a surfaced rule was actually followed, and nothing warned at propose time when a near-identical rule already existed. this adds ClaimType.LESSON and the two loops, in a new src/vouch/lessons.py.

Follow-through — observe, never edit

kb.mark_lesson_followed(claim_id, followed, context?) appends one observation to audit.log.jsonl (lesson.followed / lesson.not_followed, reversible=False) and edits nothing — not the lesson's text, status, or confidence. an observation about usage is not an edit to reviewed knowledge, so this needs no gate and has none: the module does not import proposals at all, and test_the_lessons_module_cannot_reach_the_review_gate asserts that. counts are derived from the log on read rather than stored, so there is no second copy to drift out of sync with the authoritative stream.

both verbs are added to effectiveness.GOOD_EVENTS / BAD_EVENTS, so the signal reaches the measurement it exists for (#426, already landed).

Repeat guard — warn, never merge

proposing a lesson that strongly overlaps an approved one attaches a loud repeat_lesson warning naming the existing rule. the proposal is still filed; nothing is merged or auto-approved.

it is deliberately lexical (token Jaccard over stopword-stripped tokens, threshold review.lesson_repeat_threshold, default 0.6) rather than only riding find_similar_on_propose: the embedding path needs the [embeddings] extra, and a repeat guard that silently disappears on a base install is exactly the situation where duplicate rules accumulate. it composes with the embedding warnings rather than replacing them, deduped by artifact id.

workflow and warning claims count as lessons too, so existing KBs get follow-through without re-typing their rules.

Test Plan

• tests/test_lessons.py (19 tests): the observe-not-edit invariant (byte-compares the claim yaml before/after), the no-gate-path invariant, the guard warning without blocking, the unrelated-lesson and non-lesson negative cases, configurable threshold, follow_rate is None vs 0.0 for an unobserved rule, and the effectiveness handoff
• test_capabilities four-site parity + test_hot_memory_universal_coverage green
• full CI gate

$ .venv/bin/python -m pytest tests/ --ignore=tests/embeddings -p no:warnings
2697 passed, 1 skipped in 193.10s (0:03:13)

$ .venv/bin/python -m mypy src
Success: no issues found in 120 source files

$ .venv/bin/python -m ruff check src tests
All checks passed!

Closes #428

[plind-junior]

the two invariants are the right ones and they are enforced the right way — an observation about usage is genuinely not an edit to reviewed knowledge, so keeping lessons.py free of any import of proposals and asserting that in test_the_lessons_module_cannot_reach_the_review_gate is a better guarantee than a code comment. deriving counts from the audit log on read rather than storing them is the same instinct and avoids the second copy that always drifts.

the repeat guard warning rather than merging is also correct, and doing it lexically so it survives a base install without the [embeddings] extra is the same reasoning #679 uses. no argument with either loop.

what i would want settled before merge is the VEP question, which this PR does not raise. it changes schemas/claim.schema.json — adding lesson to the claim type enum — plus models.py, plus three new kb.* methods across the four registration sites. every other PR in the queue right now carries an explicit "VEP: Not applicable — no object model, kb.* method, on-disk layout, bundle format, or audit-log shape change" section, and this one changes the object model and the method surface. by the standard the rest of the queue is being held to, this is the PR that needs one.

that is not an objection to the feature — it is that ClaimType.LESSON is written into committed yaml, so a KB that files lessons is not readable by an older vouch. that consequence deserves to be recorded somewhere durable rather than inferred from the schema diff.

one smaller thing worth confirming: treating existing workflow and warning claims as lessons is a nice migration story, but it means follow_rate starts reporting on claims whose authors never opted into being measured. None vs 0.0 for an unobserved rule is handled, so the numbers will not lie — but a reviewer seeing follow-through stats appear on rules they wrote before this landed may reasonably ask where they came from. a line in the changelog entry would cover it.

[plind-junior]

The features has been deprecated