fix(memory): deterministic deflection scrub for diary writes + bulk clean button

[isair]

Summary

Closes #259.

The summariser prompt's deflection rule (added in #232) reduces but does not eliminate "the assistant could not / offered to search / did not have…" leaks on small models. Field measurement on a real diary showed roughly 40% of post-rule writes on gemma4:e2b still contained banned phrasing, and pre-rule rows had no way to be cleaned. Once recalled by enrichment, those entries prime the next reply to repeat the deflection.

This PR brings the diary up to parity with the knowledge graph's two-layer defence (extractor BANNED FACT FORMS at write-time, deterministic merge-time rewrite for historical data) by:

1. Write-time scrub — scrub_deflection_sentences() runs on every diary write and drops whole sentences matching narrow patterns. Keeps the original if scrubbing would empty the row; an empty diary entry is worse than a slightly-leaky one. Idempotent.
2. Bulk sweep clean button — scrub_all_diary_summaries() walks every row in conversation_summaries. Surfaced via POST /api/diary/scrub-deflections (NDJSON streaming) and a "Clean up deflection narration" button under a new Maintenance section in the diary sidebar. Preserves the row's original ts_utc so the audit trail survives the sweep, and refreshes the vector embedding inline if an embed model is configured.
3. Privacy contract — the streaming progress endpoint emits only counts and dates, never raw summary text. The error value is the exception class name only (e.g. "RuntimeError"), never the stringified message, because Python exception messages can echo offending input back to the caller. The progress event shape is locked behind a whitelist regression test so any future field addition forces deliberate review.
4. Modal copy is explicit — tells users exactly what is removed (deflection sentences) and what stays (everything else, including the row itself if it would otherwise be emptied), so the clean button does not feel like a silent data-loss action. Modal log entries are constructed with textContent on real DOM nodes so a malformed date_utc or error class name cannot inject markup.

PR #281's caching scope is intentionally left untouched per the original brief.

Why this approach (vs. enrichment-side filter)

#259 originally proposed (A) summariser hygiene + (B) enrichment-side filter. With (A) hardened to a two-layer defence (prompt + scrub) and the bulk sweep cleaning historical poisoning, (B) becomes unnecessary by construction: there is no poisoned content left at recall time.

Field-driven design

The pattern set is intentionally narrow (English-first, "the assistant <failure verb>" canonical shape). False positives erase real content, which poisons the diary in a different way (silent fact loss). Precision over recall: a few residual leaks are survivable, an erased preference is not. The summariser prompt rule itself remains language-agnostic.

Field bug caught during review

Initial commit wired the diary maintenance click handler inside initGraph(), which only runs when the user opens the Knowledge tab. The diary tab is the default — meaning a user who clicked the button without ever visiting Knowledge first got no response. Fixed in the second commit (handler now lives on the always-run page setup path) and a regression test asserts the wiring is structurally outside initGraph() so a future refactor cannot reintroduce the bug.

Test plan

• 30 unit tests for the scrub function (tests/test_diary_deflection_scrub.py): pattern coverage across 13 phrase variants including the stated… and indicated… branches, edge cases (empty, idempotence, total-deflection, multi-line summaries with \n, summaries without terminal punctuation), and a write-path integration test that proves the scrub fires before the row is persisted.
• 9 DB-integration tests for the bulk sweep (tests/test_diary_scrub_sweep.py): every row visited, idempotent, fail-open per row, no diary content in event payloads, total-deflection rows kept rather than emptied, ts_utc preservation, error field contains exception class name only, embedding refresh behaviour without an embed model.
• 5 endpoint tests (tests/test_memory_viewer_diary_scrub_api.py): NDJSON streaming, write-back, privacy regression asserting diary content cannot leak via the streaming UI, progress-event key whitelist locking the shape, aggregate-count contract, regression test that the click handler is wired outside initGraph().
• Live eval (evals/test_diary_summariser_hygiene.py): defence-in-depth check that the post-scrub output is clean even when the live LLM leaks.
• 373 tests pass across the diary/memory/graph/engine surface. Pre-existing flake on tests/test_dialogue_memory.py::test_update_diary_preserves_new_messages_during_slow_llm reproduces on develop with no changes — not introduced by this PR.
• Memory viewer HTML structure verified end-to-end via Flask test client (button id, label, modal copy, endpoint wiring, CSS class, handler placement outside initGraph(), XSS-hardened log construction).

Spec / docs

• src/jarvis/memory/summariser.spec.md: post-process scrub, bulk-sweep UI, privacy contract, audit-trail and embedding-refresh contracts documented alongside the existing rules; eval/regression-guard table extended.
• docs/llm_contexts.md: summariser data flow updated to note the scrub between LLM output and DB.
• CLAUDE.md spec registry: summariser entry refreshed to reflect the two-layer defence.
• README.md: troubleshooting note for users hitting poisoned diary rows pointing at the new clean button.