feat: workspace-based multi-tenancy, replacing user as tenancy axis (#840)

Introduces `workspace` as the isolation boundary for config, flows,
library, and knowledge data. Removes `user` as a schema-level field
throughout the code, API specs, and tests; workspace provides the
same separation more cleanly at the trusted flow.workspace layer
rather than through client-supplied message fields.

Design
------
- IAM tech spec (docs/tech-specs/iam.md) documents current state,
  proposed auth/access model, and migration direction.
- Data ownership model (docs/tech-specs/data-ownership-model.md)
  captures the workspace/collection/flow hierarchy.

Schema + messaging
------------------
- Drop `user` field from AgentRequest/Step, GraphRagQuery,
  DocumentRagQuery, Triples/Graph/Document/Row EmbeddingsRequest,
  Sparql/Rows/Structured QueryRequest, ToolServiceRequest.
- Keep collection/workspace routing via flow.workspace at the
  service layer.
- Translators updated to not serialise/deserialise user.

API specs
---------
- OpenAPI schemas and path examples cleaned of user fields.
- Websocket async-api messages updated.
- Removed the unused parameters/User.yaml.

Services + base
---------------
- Librarian, collection manager, knowledge, config: all operations
  scoped by workspace. Config client API takes workspace as first
  positional arg.
- `flow.workspace` set at flow start time by the infrastructure;
  no longer pass-through from clients.
- Tool service drops user-personalisation passthrough.

CLI + SDK
---------
- tg-init-workspace and workspace-aware import/export.
- All tg-* commands drop user args; accept --workspace.
- Python API/SDK (flow, socket_client, async_*, explainability,
  library) drop user kwargs from every method signature.

MCP server
----------
- All tool endpoints drop user parameters; socket_manager no longer
  keyed per user.

Flow service
------------
- Closure-based topic cleanup on flow stop: only delete topics
  whose blueprint template was parameterised AND no remaining
  live flow (across all workspaces) still resolves to that topic.
  Three scopes fall out naturally from template analysis:
    * {id} -> per-flow, deleted on stop
    * {blueprint} -> per-blueprint, kept while any flow of the
      same blueprint exists
    * {workspace} -> per-workspace, kept while any flow in the
      workspace exists
    * literal -> global, never deleted (e.g. tg.request.librarian)
  Fixes a bug where stopping a flow silently destroyed the global
  librarian exchange, wedging all library operations until manual
  restart.

RabbitMQ backend
----------------
- heartbeat=60, blocked_connection_timeout=300. Catches silently
  dead connections (broker restart, orphaned channels, network
  partitions) within ~2 heartbeat windows, so the consumer
  reconnects and re-binds its queue rather than sitting forever
  on a zombie connection.

Tests
-----
- Full test refresh: unit, integration, contract, provenance.
- Dropped user-field assertions and constructor kwargs across
  ~100 test files.
- Renamed user-collection isolation tests to workspace-collection.

docs/tech-specs/flow-class-definition.md

@@ -20,8 +20,8 @@ Defines shared service processors that are instantiated once per flow blueprint.
 ```json
 "class": {
   "service-name:{class}": {
-    "request": "queue-pattern:{class}",
-    "response": "queue-pattern:{class}",
+    "request": "queue-pattern:{workspace}:{class}",
+    "response": "queue-pattern:{workspace}:{class}",
     "settings": {
       "setting-name": "fixed-value",
       "parameterized-setting": "{parameter-name}"
@@ -31,11 +31,11 @@ Defines shared service processors that are instantiated once per flow blueprint.
 ```
 
 **Characteristics:**
-- Shared across all flow instances of the same class
+- Shared across all flow instances of the same class within a workspace
 - Typically expensive or stateless services (LLMs, embedding models)
-- Use `{class}` template variable for queue naming
+- Use `{workspace}` and `{class}` template variables for queue naming
 - Settings can be fixed values or parameterized with `{parameter-name}` syntax
-- Examples: `embeddings:{class}`, `text-completion:{class}`, `graph-rag:{class}`
+- Examples: `embeddings:{workspace}:{class}`, `text-completion:{workspace}:{class}`
 
 ### 2. Flow Section
 Defines flow-specific processors that are instantiated for each individual flow instance. Each flow gets its own isolated set of these processors.
@@ -43,8 +43,8 @@ Defines flow-specific processors that are instantiated for each individual flow
 ```json
 "flow": {
   "processor-name:{id}": {
-    "input": "queue-pattern:{id}",
-    "output": "queue-pattern:{id}",
+    "input": "queue-pattern:{workspace}:{id}",
+    "output": "queue-pattern:{workspace}:{id}",
     "settings": {
       "setting-name": "fixed-value",
       "parameterized-setting": "{parameter-name}"
@@ -56,9 +56,9 @@ Defines flow-specific processors that are instantiated for each individual flow
 **Characteristics:**
 - Unique instance per flow
 - Handle flow-specific data and state
-- Use `{id}` template variable for queue naming
+- Use `{workspace}` and `{id}` template variables for queue naming
 - Settings can be fixed values or parameterized with `{parameter-name}` syntax
-- Examples: `chunker:{id}`, `pdf-decoder:{id}`, `kg-extract-relationships:{id}`
+- Examples: `chunker:{workspace}:{id}`, `pdf-decoder:{workspace}:{id}`
 
 ### 3. Interfaces Section
 Defines the entry points and interaction contracts for the flow. These form the API surface for external systems and internal component communication.
@@ -68,8 +68,8 @@ Interfaces can take two forms:
 **Fire-and-Forget Pattern** (single queue):
 ```json
 "interfaces": {
-  "document-load": "persistent://tg/flow/document-load:{id}",
-  "triples-store": "persistent://tg/flow/triples-store:{id}"
+  "document-load": "persistent://tg/flow/{workspace}:document-load:{id}",
+  "triples-store": "persistent://tg/flow/{workspace}:triples-store:{id}"
 }
 ```
 
@@ -77,8 +77,8 @@ Interfaces can take two forms:
 ```json
 "interfaces": {
   "embeddings": {
-    "request": "non-persistent://tg/request/embeddings:{class}",
-    "response": "non-persistent://tg/response/embeddings:{class}"
+    "request": "non-persistent://tg/request/{workspace}:embeddings:{class}",
+    "response": "non-persistent://tg/response/{workspace}:embeddings:{class}"
   }
 }
 ```
@@ -117,6 +117,16 @@ Additional information about the flow blueprint:
 
 ### System Variables
 
+#### {workspace}
+- Replaced with the workspace identifier
+- Isolates queue names between workspaces so that two workspaces
+  starting the same flow do not share queues
+- Must be included in all queue name patterns to ensure workspace
+  isolation
+- Example: `ws-acme`, `ws-globex`
+- All blueprint templates must include `{workspace}` in queue name
+  patterns
+
 #### {id}
 - Replaced with the unique flow instance identifier
 - Creates isolated resources for each flow