althing-chamber: add valkey for Phase 3.1 cross-process streaming

Phase 3.1 closes the cross-process gap the Phase 3 smoke surfaced —
streaming events (msg_start/thinking/delta/complete/curated) flow
from agent-runner → chamber via valkey pub/sub rather than the
SQLite bridge (too high-volume + ephemeral for the DB).

New service: `althing-valkey` (stock `valkey/valkey:8-alpine`).
Internal-only — no exposed port, no volume. chamber + agent-runner
reach via docker DNS at `valkey:6379` on the compose default
network. healthcheck via `valkey-cli ping` (5s interval). chamber
+ agent-runner gain `depends_on: valkey: service_healthy` so the
bridge is up before either side starts publishing or subscribing.

Forseti unchanged — never publishes Phase 3 events.

Operational properties (per forseti's deployment notes):
  - Mixed-state safe at every step. Missing valkey.url config key
    → chamber + runner stay on v3.0 / Phase 2 equivalent paths.
  - Backward path is single config-key delete + restart.
  - streaming_enabled: true (set on agent-runner 2026-05-17) is
    unaffected by this change.

README's services table + playbook header + verify section all
extended to reflect the four-service shape. Forseti's contract
at vh/althing:docs/contracts/phase3_1_valkey_bridge.contract.md
carries the wire-protocol spec.

stacks/althing-chamber/README.md

@@ -1,13 +1,15 @@
 # althing-chamber
 
-Web UI + moderator daemon + agent-runner for the althing inter-agent
-message bus. Three services share a single SQLite store via a
-bind-mount; the chamber serves FastAPI/HTMX, the forseti daemon runs
-the moderation + curation loops, and the agent-runner daemon claims
-floor grants for worldtree-driver agents and dispatches them to
-Worldtree's conversation API. Cross-process glue is
-`eventbus.bridge_from_db` polling the same DB all three processes
-write.
+Web UI + moderator daemon + agent-runner + Valkey IPC bridge for the
+althing inter-agent message bus. Four services on the compose default
+network. The chamber serves FastAPI/HTMX, the forseti daemon runs the
+moderation + curation loops, the agent-runner daemon claims floor
+grants for worldtree-driver agents and dispatches them to Worldtree's
+conversation API, and Valkey carries the Phase 3.1 cross-process
+streaming events (msg_start/delta/thinking/complete/curated) that are
+too high-volume to flow through SQLite. SQLite-backed state still
+shares between chamber + forseti + agent-runner via the bind-mount;
+streaming events ride pub/sub on the docker default network.
 
 **Server:** ana-docker
 **URL:** `http://10.250.50.70:7881` (configurable via `.env`)
@@ -22,10 +24,13 @@ by the deploy playbook. Not pulled from a registry.
 | `althing-chamber` | FastAPI/HTMX web UI; SSE subscribers; `/health` endpoint | host 7881 → container 8000 | `python urllib /health` |
 | `althing-forseti` | Moderator + curator daemon; writes events that chamber's bridge picks up | — (no HTTP) | none (process-up signal only) |
 | `althing-agent-runner` | Phase 2: claims worldtree-driver floor grants and dispatches to Worldtree's conversation API | — (no HTTP) | none (process-up signal only) |
+| `althing-valkey` | Phase 3.1: Valkey 8 redis-protocol pub/sub bridge — carries streaming events from agent-runner → chamber | — (internal-only, `valkey:6379` on default network) | `valkey-cli ping` |
 
-All three use the same `${ALTHING_IMAGE}`; the `command:` line in compose
-picks which entrypoint (`althing-chamber` / `althing-forseti` /
-`althing-agent-runner`) runs in each container.
+The three althing services (chamber/forseti/agent-runner) use the same
+`${ALTHING_IMAGE}`; the `command:` line in compose picks which entrypoint
+runs in each container. Valkey is a stock upstream image (no custom build).
+chamber + agent-runner `depends_on: valkey: service_healthy` so the pub/sub
+bridge is up before either side starts publishing or subscribing.
 
 The agent-runner is safe to enable preemptively — when no
 `driver=worldtree` handles are declared in config, it polls