feat: complete catalog sensitivity enhancements

docs/operations/database-management.md

@@ -60,7 +60,8 @@ remains available only until the integrated Fleet Ledger surface passes owner ac
    complete the binding fields that the chosen transport requires.
 3. Enter secrets only when replacing them. They remain write-only and are never returned by the
    application.
-4. Run **Test connection** before any synchronization.
+4. Use **Test connection** whenever you want an informational connectivity check. Its result does
+   not enable or disable catalog operations.
 
 SSH uses a private key, optional key passphrase, mandatory `known_hosts`, and optional PostgreSQL
 TLS CA/server name. REST prefers `POST /rpc/schema_snapshot`; when it is absent, the catalog may
@@ -71,7 +72,9 @@ capability, malformed snapshot, or connector error applies no catalog changes. S
 ## Synchronize authoritative schema metadata
 
 Schema synchronization reads the external database and reconciles the installation-local catalog.
-It never changes the source database. The available synchronization scopes are **tables**,
+It never changes the source database. Every synchronization attempts a fresh connection when it
+runs; an unreachable server or rejected credential fails that run without changing catalog data.
+The available synchronization scopes are **tables**,
 **columns**, **relationships**, and **all**, but the UI exposes them at different levels:
 
 | Location | Action | Effective scope |
@@ -88,10 +91,10 @@ The selection requirement in the tables and columns views controls whether the a
 be used; it is not always the same as the synchronization target. The **Sync all** button in the
 tables view is the direct shortcut for the full-database scope.
 
-Before starting any synchronization, run **Test connection**. Synchronization is rejected when
-the binding is unreachable or its tested version is older than the current binding configuration.
-Only one catalog operation can be active for a database at a time; explicit cleanup shares this
-exclusion.
+Connection tests are informational and are never a synchronization prerequisite. Each
+synchronization tests its own access while reading the schema; an unavailable connection fails
+that operation with a connector error. Only one catalog operation can be active for a database at
+a time; explicit cleanup shares this exclusion.
 
 ### What a synchronization does
 
@@ -167,6 +170,12 @@ starting generation. Changing a flag affects future generations only; existing g
 descriptions are not regenerated. Real and substituted samples remain transient and are not persisted
 or returned to the browser.
 
+The database-level **Copy generated descriptions to all columns** action applies every non-empty
+AI-generated column description to the corresponding curated **Description** field in one atomic
+operation. It skips empty generated descriptions, reports copied and skipped counts, and retains the
+generated text. Because this can replace reviewed descriptions, the interface requires explicit
+confirmation before applying it.
+
 The decisions behind this surface are [ADRs 0001–0011](../adr/0001-postgres-metadata-catalog.md)
 and the detailed acceptance record is
 [AI catalog description generation acceptance](../testing/2026-08-29-ai-catalog-description-generation-acceptance.md).

docs/operations/sensitivity-analysis.md

@@ -7,9 +7,13 @@ may set either value, including overriding a `sensitive` proposal.
 
 ## Default policy
 
-`SensitivityClassifier` is the only column-level decision point. The versioned `sensitivity-v2`
+`SensitivityClassifier` is the only column-level decision point. The versioned `sensitivity-v4`
 policy combines:
 
+- a structural exclusion for declared `bigint` primary-key columns and undeclared `bigint`
+  columns following the exact `pk` naming convention; their values are non-informative identifiers
+  and are therefore not inspected as possible sensitive content. The evidence distinguishes
+  declared constraints from convention-based inference;
 - normalized column-name rules for direct identifiers, credentials, and health data;
 - validated content rules for email, Italian fiscal code and VAT, passport, identity-card and
   driving-licence identifiers, phone numbers, IBAN/BIC, payment-card checksums, IP/MAC addresses,
@@ -46,7 +50,7 @@ and returns no review instead of manufacturing `unknown` decisions.
 There is no global sixty-second analysis deadline. Work is bounded by sample counts, per-query
 timeouts, and early column exits. The operation is interrupted only when its request connection is
 aborted or the backend restarts. Historical or interrupted run counters named `unknown` represent
-columns that were not processed; `unknown` is not a `sensitivity-v2` column assessment.
+columns that were not processed; `unknown` is not a `sensitivity-v4` column assessment.
 
 History stores only the policy version, aggregate outcomes, timestamps, and fixed operational
 events. Sanitized rule IDs are returned in the transient review and shadow report, not persisted.

docs/operations/workspaces.md

@@ -36,8 +36,10 @@ the curator-owned repository during pull.
    keys, or signed URLs in this repository.
 2. In the application, update the workspace repository. This fetches and validates the candidate;
    it never edits the remote repository.
-3. Select the workspace. Supply or replace its write-only runtime secrets, then run **Validate
-   workspace source** and **Test workspace connections**.
+3. Select the workspace. Supply or replace its write-only Evidence runtime secrets, configure its
+   database in **Database Management**, then run **Validate workspace source** and **Test workspace
+   connections**. The workspace connection test uses that same current database configuration for
+   DWH connectivity and also checks the workspace Evidence and installation semantic services.
 4. Select it as the installation workspace before creating sessions.
 5. Use the host CLI for preprocessing. It dispatches a profile-gated maintenance service and
    returns a single structured result; `--json` keeps stdout machine-readable.
@@ -71,8 +73,9 @@ forms and the schema-v4 descriptor contract, see
 ## Transport and revision rules
 
 Runtime sessions support direct PostgreSQL and REST bindings. SSH tunnel bindings are diagnostic
-only for this path, so they cannot admit an NL→SQL session. Database Management has its own
-strict known-host SSH path for connection tests and schema synchronization.
+only for this path, so they cannot admit an NL→SQL session. Database Management and **Test
+workspace connections** share the current database binding, including its strict known-host SSH
+path; the remaining workspace diagnostics cover Evidence and installation semantic services.
 
 Every new session pins the active Git revision. Snapshot cleanup retains revisions still
 referenced by unarchived sessions. A later pull can prepare a future session but cannot alter a