feat: implement metadata catalog database management

docs/adr/0001-postgres-metadata-catalog.md

@@ -2,10 +2,12 @@
 
 ThothII userà un Metadata Catalog PostgreSQL interno per conservare, per ogni workspace, la
 struttura fisica acquisita interrogando il relativo database e i metadati semantici generati con
-l'AI. Ogni workspace avrà un solo Workspace Database; identità e lista dei workspace resteranno
-autorevoli in `thoth-workspaces.yaml`, mentre il catalogo ne conserverà soltanto il riferimento
-stabile. `schema/annotations.yaml` verrà sostituito come input del core in uno step successivo;
-l'interfaccia e il lifecycle amministrativi resteranno separati dal workflow NL→SQL.
+l'AI. Ogni Workspace Database conserverà un `workspace_id` obbligatorio e univoco: questo realizza
+l'associazione uno-a-uno senza introdurre nel catalogo una tabella Workspace o una foreign key SQL.
+Identità e lista dei workspace resteranno autorevoli in `thoth-workspaces.yaml`; il servizio
+validerà il riferimento contro quel catalogo. `schema/annotations.yaml` verrà sostituito come input
+del core in uno step successivo; l'interfaccia e il lifecycle amministrativi resteranno separati dal
+workflow NL→SQL.
 
 ## Considered Options
 
@@ -18,4 +20,7 @@ l'interfaccia e il lifecycle amministrativi resteranno separati dal workflow NL
 
 PSD importerà le annotations esistenti; gli altri workspace genereranno i metadati da zero. Il
 cutover futuro dovrà sostituire consapevolmente i consumatori delle annotations e verificarne
-l'equivalenza semantica. Le sessioni di test esistenti non sono un vincolo di migrazione.
+l'equivalenza semantica. PostgreSQL può garantire che uno stesso `workspace_id` non sia assegnato a
+due database, ma l'esistenza del workspace e la gestione di rename o rimozioni restano responsabilità
+del confine applicativo con il catalogo YAML. Le sessioni di test esistenti non sono un vincolo di
+migrazione.