feat: classify sensitive columns locally

docs/architecture/components.md

@@ -104,11 +104,19 @@ or second orchestration subsystem. A target receives at most one provider retry;
 exhausted technical batches fail the run. Stale work is marked interrupted at startup and must be
 explicitly unlocked; it never resumes automatically.
 
-Sensitive-field suggestion generation remains a synchronous administrative request, but each
-attempt has its own durable run and ordered sanitized events. This history is separate from
-Description Generation because its lifecycle and counters differ. Only execution metadata and
-aggregate counts are stored; proposed flags, prompts, raw model output, and provider diagnostics
-remain transient.
+Sensitivity analysis is a synchronous administrative request and does not use the installation
+model catalog. Database-specific adapters stream bounded normalized values from read-only source
+connections; the TypeScript `SensitivityClassifier` is the single decision point for
+`sensitive | non_sensitive | unknown`. Deterministic rules run first. A complete scan is attempted
+for at most five seconds per table, then the adapter samples within the sixty-second request budget.
+An optional offline GLiNER2 worker may add NER evidence on CPU for unresolved short text, but it
+cannot make or persist the decision itself.
+
+Each attempt has its own durable run and ordered sanitized events, separate from Description
+Generation because its lifecycle and counters differ. The run records the local policy version,
+coverage aggregates, and sanitized rule identifiers. Proposed flags, source values, NER spans, and
+worker diagnostics remain transient. Only an explicit administrator save changes the human-owned
+Sensitive Data Flag.
 
 ## Main backend classes