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/docs/log-sanitization.md

@@ -21,6 +21,11 @@ scan (see `privacy-scan.md`). ADL-067.
 - **No marker.** Nothing is stamped into the file.
 - **Idempotent.** The fillers are on the privacy allowlist (`isRedactionFiller`),
   so a re-scan finds nothing and a second `Sanitize` is a no-op.
+- **Detectable.** The privacy scan reports an already-sanitized file in
+  `PrivacyScan.Sanitized` - see `privacy-scan.md`. It needs corroborating
+  markers, so a single filler-looking token (or a partial future redaction
+  pass) does not read as "done", and the UI hides the sanitize button when a
+  file already looks de-identified.
 
 ## Entry point