doc(README, issue): adopt gonzo for log viewing — the right-sized observability tier

Add a README Observability section and wire gonzo into the API-speed issue:
brew install gonzo (or nix run github:control-theory/gonzo) — a k9s-style
real-time log-analysis TUI. Pipe `docker compose logs -f | gonzo` or
`railway logs --service <svc> | gonzo` to watch the cross-service boot handshake
while the browser prints its performance.now() timings. OTLP receiver is the
tracing bridge if/when needed; no metrics/tracing platform at one user.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UYTYu4MAFZ7iyr2VTo2kq

Author: mpstaton

README.md

@@ -180,6 +180,34 @@ Notes:
 - **The E2E group (I)** stands up a disposable backend (throwaway Docker NATS + in-memory SurrealDB + the resolver, workspace-service, and content-ingest) and tears it down after — so it needs **Docker running** and the `surreal` CLI. It uses ports `3199`/`4223`; if an interrupted run leaves anything behind, clear it with `docker rm -f augment-e2e-nats` and `pkill -f "tsx src/server.ts"`.
 - **No `ws` package** — the transport tests run against a hand-rolled RFC-6455 server and every client uses the platform-native `WebSocket`.
 
+## Observability
+
+At current scale (single operator) there is **no metrics/tracing platform** —
+that would be over-engineering. Log viewing is handled by
+[**gonzo**](https://github.com/control-theory/gonzo), a k9s-style real-time
+log-analysis TUI (streaming charts, pattern detection, filtering, an optional
+OTLP receiver). Install it with:
+
+```bash
+brew install gonzo
+# or, from the monorepo dev shell: nix run github:control-theory/gonzo
+```
+
+Gonzo reads stdin/pipes, files, or OTLP — so point any service log stream at it:
+
+```bash
+docker compose logs -f | gonzo          # the whole local backend stack, live
+railway logs --service workspace-service | gonzo   # a deployed service
+gonzo -f ./some-service.log --follow    # a captured file
+```
+
+This is the tooling home for the boot-latency work in
+[`context-v/issues/Refactoring-for-API-Speed.md`](context-v/issues/Refactoring-for-API-Speed.md):
+watch the cross-service handshake (workspace-service → resolver → content-ingest)
+in one pane while the frontend prints its own `performance.now()` boot timings in
+the browser console. Gonzo's OTLP receiver (`--otlp-enabled`) is the bridge if we
+ever add tracing — but that's deferred until team scale, not one user.
+
 ## Deployment
 
 The humain-vc single-tenant instance runs live on **Railway** at

context-v/issues/Refactoring-for-API-Speed.md

@@ -95,7 +95,20 @@ below is gated on what it shows. Pair it with the browser Network waterfall
 (free) and, if cross-service correlation is needed, a request_id threaded
 shell → workspace-service → resolver (deferred until tier-1 proves insufficient).
 
-A full observability stack (OTel/Prometheus/dashboards) is **explicitly not
+For the **server side** of the same picture, view the service logs with
+[**gonzo**](https://github.com/control-theory/gonzo) — a k9s-style real-time
+log-analysis TUI (`brew install gonzo`, or `nix run github:control-theory/gonzo`
+from the monorepo dev shell). Pipe the cross-service handshake into one pane
+while the browser prints its boot timings:
+
+```bash
+docker compose logs -f | gonzo                       # local backend stack
+railway logs --service workspace-service | gonzo     # a deployed service
+```
+
+Gonzo's OTLP receiver (`--otlp-enabled`, gRPC 4317 / HTTP 4318) is the bridge if
+tier-1 timings + logs prove insufficient and we add real tracing. A full
+observability stack (OTel pipelines/Prometheus/dashboards) is **explicitly not
 needed** at one user — same right-sizing thesis. Boot instrumentation lives near
 [[No-User-Visibility-Into-State-Needs-A-State-Inspector]] / the live-not-live
 indicator work.