docs: a check-in needs the project UUID, not the slug

WORK_CYCLE.md's check-in example passed "projectId":"<slug>", which every other
route on this API takes. This one does not: a slug is rejected with
{"error":{"code":"unknown","message":"Something went wrong."}} — a message that
names no field and reads like an outage. Cost two failed posts before the cause
was found, on the run that wrote the entry above.

The section now reads the id off the project first, and the extraction command
in it was run against the live API rather than written from memory. Also records
that there is no route to amend a check-in once posted, so the body has to be
right on the first send.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/WORK_CYCLE.md

@@ -245,11 +245,21 @@ curl -sk -X PATCH -H "$AUTH" -H "Content-Type: application/json" \
 
 **A check-in** — a timestamped "what changed", when there is something real to
 report. `summary` is required and must say something; the API refuses an empty
-"no change" update, deliberately:
+"no change" update, deliberately.
+
+**`projectId` here is the project's UUID, not its slug** — unlike every other
+route on this API, which takes the slug in the path. A slug is rejected with
+`{"error":{"code":"unknown","message":"Something went wrong."}}`, which says
+nothing about which field was wrong and looks exactly like an outage. Read the
+`id` off the project first. There is also **no route that amends a check-in**
+once posted, so get the body right before sending it:
 
 ```bash
+PID=$(curl -sk -H "$AUTH" "$BASE/agent/projects/<slug>" \
+        | python3 -c "import json,sys; print(json.load(sys.stdin)['project']['id'])")
+
 curl -sk -X POST -H "$AUTH" -H "Content-Type: application/json" \
-  -d '{"projectId":"<slug>","health":"on_track",
+  -d '{"projectId":"'"$PID"'","health":"on_track",
        "summary":"<what changed>","accomplishments":"<what landed>",
        "blockers":"<what is stuck, or omit>","nextActions":"<what is next>"}' \
   "$BASE/agent/updates"