docs(spec): pin why the git observer runs on the host, not in BIT's container

Batch job not request handler; volume mounts would rot as projects are added;
HTTP keeps the observer relocatable to another machine. BIT stays in Docker.

docs/superpowers/specs/2026-09-02-project-cadence-design.md

@@ -238,10 +238,23 @@ through the existing JSON import.
 Ships **with BIT**, in BIT's repo. Deterministic Python, no model, no knowledge of
 Brian — it produces facts, which is why it lives here.
 
-**Deployment note:** BIT runs in Docker; the git repos live on the host. So the
-observer runs **on the host** (cron or systemd timer) and POSTs to BIT's API like
-any other client. That avoids volume-mounting every repo into the container while
-keeping the code in BIT's repo where it belongs.
+**Deployment note:** BIT stays in Docker. The observer ships in BIT's repo but
+runs **on the host** (systemd timer preferred over cron — better logging and
+`systemctl status`), POSTing to BIT's API like any other client.
+
+This is not a workaround for Docker; it is correct regardless:
+
+1. **It's a batch job, not a request handler.** It runs on a schedule and exits.
+   That doesn't belong in a web container's lifecycle either way.
+2. **Volume-mounting repos would rot.** Every new project would require editing
+   `docker-compose.yml` — exactly the kind of manual upkeep step that goes stale,
+   which is the failure mode this whole project exists to fix. A path in a config
+   table costs nothing.
+3. **HTTP decouples it usefully.** The observer can later run on a different
+   machine entirely (the Windows box, for repos that live there) with no code
+   changes. Putting it inside the container throws that away.
+
+Requires `git` and Python on the host, both already present.
 
 ### Config