Merge origin/codex/portable-deployment into feat/docker-local-deploy

Unisce gli internals di Codex (secret-bundle, provider-credentials, auth upstream,
security hardening, CI multiarch) mantenendo le fix portal-specific:
- backend: configPath da THT_CONFIG (fix sessioni) + dataRoot di Codex; authMode 'upstream'
- Docker/compose: TENUTO il mio (verificato live: omics_network+alias, env_file, pi npm-g)
  perche' il compose/Dockerfile/entrypoint di Codex sono accoppiati al suo modello
  secret-bundle (tht doctor inesistente, secret-policy.sh). Adottabile in futuro.
- config.test.ts: preso Codex (superset)
Verificato: tsc clean, 132/132 vitest.

harness/workspaces/tht.example.yaml

@@ -1,26 +1,19 @@
 # Workspace ThothII (esempio). I segreti vivono SOLO in .env (${THT_*}).
-# La struttura rispecchia esattamente tht/config.py:
-# database + rest per il DWH; vector_rest/vector_write_rest per il pgvector (doppia key);
-# vector_db per il loading diretto (server-only); embeddings + evidence + execution.
+# Ogni risorsa dichiara il proprio adapter tramite `type`.
 
 language: it  # descrizioni tabelle/colonne ed evidence sono in italiano (PSD)
 
-database:
-  host: ${THT_DB_HOST}
-  port: ${THT_DB_PORT}             # es. 5437 (Postgres diretto Supabase; 5432 = pooler)
-  database: ${THT_DB_NAME}         # es. postgres (lo schema a stella vive in `datawarehouse`)
-  schema: datawarehouse
-  user: ${THT_DB_USER}
-  password: ${THT_DB_PASSWORD}
-  transport: rest                    # direct (Postgres) | rest (Supabase/PostgREST)
+dwh:
+  type: thoth_rest                  # postgres_direct | thoth_rest
+  database:
+    database: ${THT_DB_NAME}
+    schema: datawarehouse
+  endpoint:
+    base_url: ${THT_DWH_REST_URL}
+    api_key: ${THT_DWH_API_KEY}
+    ssl_ca: ${THT_SSL_CA}
 
-# Accesso al DWH via REST (richiesto se database.transport = rest).
-rest:
-  base_url: ${THT_DWH_REST_URL}    # es. https://supabase-aritmolab.policlinicosandonato.it/dwh/
-  api_key: ${THT_DWH_API_KEY}      # header X-API-Key, ruolo dwh_reader (read-only)
-  ssl_ca: ${THT_SSL_CA}            # path al certificato CA (per server con CA interna)
-
-paths:
+roots:
   artifacts: artifacts
   indexes: indexes
   sessions: sessions
@@ -50,30 +43,23 @@ embeddings:
   dim: 768
   batch_size: 32
 
-# LOADING del pgvector: connessione diretta, eseguita sul server (profilo server).
-# Opzionale su postazione remota (lì la lettura passa da vector_rest).
-vector_db:
-  host: ${THT_VEC_HOST}            # Postgres locale del server
-  port: ${THT_VEC_PORT}            # es. 5437
-  database: postgres
-  schema: vectors
-  user: ${THT_VEC_USER}
-  password: ${THT_VEC_PASSWORD}
-
-# LETTURA (similarity search) del pgvector via REST remota: rpc search_similar.
-vector_rest:
-  base_url: ${THT_VEC_REST_URL}    # es. https://host/vector/v1/
-  api_key: ${THT_VEC_API_KEY}      # header X-API-Key, ruolo vector_reader (read-only)
-  ssl_ca: ${THT_SSL_CA}
-
-# SCRITTURA controllata del pgvector via REST remota: upsert/hash via RPC allowlist,
-# niente delete/clear. Usa una API key SEPARATA dalla lettura (ruolo vector_writer).
-# OPZIONALE: assente o key vuota = scrittura non abilitata (solo lettura).
-# Abilita tht memory save-one / vector index-schema da postazione remota.
-vector_write_rest:
-  base_url: ${THT_VEC_REST_URL}
-  api_key: ${THT_VEC_WRITE_API_KEY}
-  ssl_ca: ${THT_SSL_CA}
+vectors:
+  type: thoth_vector_http           # pgvector_direct | thoth_vector_http
+  reader:
+    base_url: ${THT_VEC_REST_URL}
+    api_key: ${THT_VEC_API_KEY}
+    ssl_ca: ${THT_SSL_CA}
+  writer:                           # opzionale: credenziale separata dalla lettura
+    base_url: ${THT_VEC_REST_URL}
+    api_key: ${THT_VEC_WRITE_API_KEY}
+    ssl_ca: ${THT_SSL_CA}
+  direct:                           # opzionale: loading server-side diretto
+    host: ${THT_VEC_HOST}
+    port: ${THT_VEC_PORT}
+    database: postgres
+    schema: vectors
+    user: ${THT_VEC_USER}
+    password: ${THT_VEC_PASSWORD}
 
 vector:
   max_chunk_chars: 4000