feat: complete catalog sensitivity enhancements

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