A cache consumer presents the login it was granted, checked over the catalogue; the two-node bed's baserow keeps its own cache and the bed asserts it answers (issue 081)

scenarios/two-node-db.yml

@@ -3,7 +3,8 @@
 # The app-postgres provider and the mesh's own foundation store both want host port 5432, so they
 # cannot share a machine — the collision that blocked this chain single-node. Here the foundation
 # (store, broker, control) lives on `anchor` and NOTHING else; `laptop` runs the whole chain —
-# postgres and redis PROVIDERS plus the baserow and letta CONSUMERS that require them. Both
+# the baserow and letta CONSUMERS of the one store (baserow keeps its cache inside its own container,
+# novox/hq 081). Both
 # machines sit on one shared segment and enrol into the one mesh; only enrolment crosses to anchor,
 # over the underlay both machines already share. Provider and consumers are co-located on laptop, so
 # no cross-node module comms and no overlay are needed — and the 5432-vs-foundation conflict is gone
@@ -25,8 +26,7 @@ machines:
     inbound: allow
     memory: 4GiB
     cpus: 4
-  # The whole DB-consumer chain: postgres + redis providers, each a server and a broker-bound
-  # runtime, plus the baserow and letta consumer services and their tools runtimes — a dozen
+  # The DB consumers: the baserow and letta services and their tools runtimes — a handful of
   # containers, two of them memory-hungry app servers (the Baserow all-in-one and the Letta server).
   # At the 2GiB the two-nodes bed gives this machine it would thrash — its own anchor comment says
   # so — and convergence would present as "the mesh hangs". Six gigabytes gives it room.
@@ -49,7 +49,6 @@ images:
   # provisioner (ADR 0048).
   - mesh-runtime-postgres:development
   - mesh-runtime-lavinmq:development
-  - mesh-runtime-redis:development
   - mesh-runtime-baserow:development
   - mesh-runtime-letta:development