feat: consolidate database management work

Add catalog-owned logical relationships and runtime snapshots, extend the database-management UI and validation coverage, and document the updated operational workflow.

Keep active sensitive-generation status in a tooltip and indicator, and update the layout E2E to follow the history action in its new database-scoped location.

docs/operations/database-management.md

@@ -6,7 +6,7 @@ session workflow.
 
 ## What the catalog owns
 
-For each YAML workspace, an administrator may create at most one database configuration. It holds
+For each YAML workspace, an administrator may configure at most one Metadata Catalog binding. It holds
 the database name, schema, connection binding, write-only encrypted secrets, observed physical
 schema, optional curated descriptions, generated descriptions, and durable operation history.
 
@@ -27,6 +27,18 @@ It uses `GET /catalog/metrics` without `databaseId` for installation totals and
 the current database. Choose a selection-scoped operation from the action selector and then press
 **Run**; unavailable operations remain listed with an explanation. Row-specific actions are the icon
 controls in the final column, and each navigation or action icon has an immediate conceptual tooltip.
+An unconfigured workspace exposes **Configure catalog** directly on its row; there is no global
+database-creation action and the selected workspace cannot be changed in the configuration form.
+
+The master grid keeps three independent states visible:
+
+- **Revision / Evidence** comes from the active immutable workspace revision. Filesystem Evidence is
+  materialized with that revision; remote Evidence is reported as configured-but-unverified or as
+  requiring credentials.
+- **NL→SQL runtime** is calculated from the workspace DWH/Evidence requirements and runtime secret
+  store. It also reports transports, such as SSH, that are diagnostic-only and unsupported by sessions.
+- **Metadata Catalog** reports whether the installation-local catalog configuration exists, then shows
+  its separately versioned connection-test or synchronization state.
 
 Configuration, object details, metadata editors, synchronization history, description history,
 sensitive-field review, and suggestion-run history open in right-side drawers backed by the
@@ -42,8 +54,9 @@ remains available only until the integrated Fleet Ledger surface passes owner ac
 
 ## Configure and test a database
 
-1. Open **Database Management** and choose a workspace.
-2. Create its PostgreSQL configuration. Choose `postgres_direct`, `rest_api`, or `ssh_tunnel` and
+1. Open **Database Management** and find the repository workspace marked **Not configured**.
+2. Choose **Configure catalog** on that row. Configure its PostgreSQL catalog binding with
+   `postgres_direct`, `rest_api`, or `ssh_tunnel` and
    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.

docs/operations/docker-refresh.md

@@ -0,0 +1,43 @@
+# ThothII Docker refresh
+
+The active local `psd-local` stack uses the operator environment generated for the installation:
+
+`deploy/psd/operator.env`
+
+It is not `deploy/thothii.env` (that file is empty) and `deploy/env/local.env` is only an example
+path referenced by the generic launcher. The running stack also uses these Compose overlays:
+
+```text
+compose.yaml
+deploy/compose.local.yaml
+deploy/compose.git-ssh.yaml
+deploy/psd/connector-secrets.yaml
+```
+
+Refresh the stack from the repository root with:
+
+```bash
+compose_psd=(
+  docker compose
+  --env-file deploy/psd/operator.env
+  -p thothii-18998cca7b0a
+  -f compose.yaml
+  -f deploy/compose.local.yaml
+  -f deploy/compose.git-ssh.yaml
+  -f deploy/psd/connector-secrets.yaml
+)
+
+"${compose_psd[@]}" config --quiet
+"${compose_psd[@]}" build core frontend
+"${compose_psd[@]}" stop core frontend
+"${compose_psd[@]}" up -d catalog-db
+"${compose_psd[@]}" run --rm catalog-migrate
+"${compose_psd[@]}" up -d --remove-orphans
+```
+
+Building before the stop keeps the existing application available if an image fails to compile.
+Stopping only `core` and `frontend` prevents the old backend from using a newly migrated catalog;
+the database, Qdrant, embedding service, named volumes, and installation state remain in place.
+
+The installation secret files referenced by that env file live under `deploy/psd/secrets/` and
+must never be committed or printed.