feat(privacy): detect an already-sanitized source

Scan now reports PrivacyScan.Sanitized {detected, markers, strong, files,
evidence}. SanitizationMarkers recognises a value slot filled with one
repeated placeholder + separators (xxxxx.xxxx.xx, x@xxxx.xxxx.xx,
000.00.00.0, a decoy timezone) - it matches the shape, not the literal "x",
so evolving the redaction mechanism still trips it.

detected requires corroboration: strong>=2, or strong>=1 && markers>=3, or
markers>=4. A single filler-looking token is reported (markers:1) but never
asserted as sanitized, so a partial future pass or a coincidence does not
read as "done". 0.0.0.0 / 000 / UTC / Etc/UTC are too plausibly intentional
and do not count.

UI: the Customer-data panel shows "файл уже обезличен" and hides the
sanitize button when detected.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014jDYM1nnoZZ3vFz23DDaV1

bible-local/10-decisions.md

@@ -1974,6 +1974,10 @@ with **same-length neutral fillers**, in place.
   reported, not edited.
 - Re-parsing a sanitized dump yields the identical hardware inventory
   (verified on Dell TSR, xFusion, Inspur onekeylog, H3C `.sds`).
+- The scan detects an already-sanitized source
+  (`PrivacyScan.Sanitized`, `privacy/sanitized.go`): it matches the *shape*
+  of a filled value slot, not the literal `x`, and needs corroborating
+  markers so a partial future redaction pass does not read as "done".
 - Full contract and rule list: `bible-local/docs/log-sanitization.md`.
 - Tests: `internal/sanitize` (`TestRedactText_*`, `TestSanitize_Tar*`,
   `TestSanitize_Zip_*`, `TestSanitize_BinaryMemberFlagged`,