fix(pipelock): verify and document sidecar argv against pinned image

PR #1 reviewer flagged the sidecar argv as unverified. Pulled the pinned
digest (ghcr.io/luckypipewrench/pipelock@sha256:3b1a39…6de9), inspected
ENTRYPOINT (`/pipelock`) and CMD (`run --listen 0.0.0.0:8888`), and read
`pipelock run --help` directly from the image. The forward-proxy listen
flag is `--listen` (no `--mcp-` prefix) — `--mcp-listen` is for the
separate MCP HTTP listener, not the forward proxy we use. Smoke-tested
the exact argv against the digest and confirmed the /health endpoint
responded on :8888.

The argv was already correct; this commit records the verification in a
load-bearing comment so future readers don't have to re-derive it.

Assisted-by: Claude Code

lib/pipelock.sh

@@ -330,6 +330,20 @@ pipelock_start() {
   # boot it with `sh -c 'mkdir + sleep'`, cp the file in, then start
   # the real pipelock by docker exec'ing it as PID-N. A simpler
   # approach: `docker create` + `docker cp` + `docker start`. Use that.
+  #
+  # Sidecar argv verification (PR #1 review). The pinned digest
+  # (CLAUDE_BOTTLE_PIPELOCK_IMAGE above) has:
+  #   ENTRYPOINT ["/pipelock"]
+  #   CMD        ["run", "--listen", "0.0.0.0:8888"]
+  # `pipelock run --help` documents `-l, --listen` (default
+  # 127.0.0.1:8888) as the forward-proxy listen address — the
+  # `--mcp-listen` flag is for the separate MCP HTTP listener and is
+  # not what we want here. `--config` reads the YAML and hot-reloads
+  # on file change; values in YAML can also drive the listen address
+  # via `fetch_proxy.listen`, but the CLI flag takes precedence and
+  # is the simpler contract for our launcher. Smoke-tested 2026-05-08
+  # by running this exact argv against the digest and confirming the
+  # /health endpoint responded on :8888.
   if ! docker create \
       --name "$name" \
       --network "$internal_network" \