docs(skill): fix the run-endpoint claim and the Flow cross-references

Four documentation defects found while analysing the agent skill against the
code it drives.

The lineage section attributed "deletes its session as soon as the one-shot
prompt returns" to `POST /api/v1/sessions/:id/run`. That is true of
`POST /api/v1/run`, which creates a throwaway session and calls cleanupSession
on both the success and the error path; the per-session route deletes nothing.
Name the right endpoint, and give the real reason the per-session one carries
no lineage: it is not a create call.

While verifying that, the per-session route turned out to be a sharper trap
than documented. `runPrompt()` rejects whenever a PTY already exists, which is
every interactive session, but the route has already returned `{}` with HTTP
200 by then and routes the rejection only to SSE. An agent calling it against
a live worker reads the 200 as delivery. Document it.

`Flow 3b` never existed in recipes.md. The real mapping is Flow 3 = shell
fan-out, Flow 4 = claude fan-out, Flow 5 = worker blocked on a prompt, so the
same sentence was also mislabelling Flow 4. Fixed in SKILL.md and in the
endpoints.md reference to it; every other Flow reference audited and correct.

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

skills/codeman/SKILL.md

@@ -342,7 +342,10 @@ instead of the real cause.
 ⚠️ `POST /api/v1/sessions/:id/run` looks like the obvious "just run this prompt" call
 and is a trap: it 409s on a busy session, is fire-and-forget with no wait
 integration, and belongs to the legacy JSON-stream path whose `GET .../output` is
-always empty for interactive sessions. Use `/input`.
+always empty for interactive sessions. Against an interactive session it is worse than
+useless: it answers **200 with an empty body** and does nothing, because the reply goes
+out before the spawn is attempted and the spawn then fails ("Session already has a
+running process") into the SSE stream you are not reading. Use `/input`.
 
 **Fan-out means worktrees.** N workers on one repo means N `git worktree add`
 directories, one worker each. See the safety rule in §4 for what sharing a checkout
@@ -373,9 +376,11 @@ It is **decoration, and resolved rather than trusted**, so treat it accordingly:
   responsible for a child, deleting a parent does not touch its children, and it grants
   no rights over them. Never branch on it and never use it to decide what you may touch.
   Your `CREATED` list, not this field, is what authorizes a delete ([§4](#4-safety-rules)).
-- `POST /api/v1/sessions/:id/run` is deliberately not wired for it: that call deletes its
+- `POST /api/v1/run` is deliberately not wired for it: that call creates a throwaway
-  session as soon as the one-shot prompt returns, so the line would point at a tab that
+  session and deletes it as soon as the one-shot prompt returns (on the error path too),
-  no longer exists.
+  so the line would point at a tab that no longer exists. `POST /api/v1/sessions/:id/run`
+  carries no lineage either, for a duller reason: it creates nothing, it runs a prompt in
+  a session that already exists.
 
 ### 5.2 Readiness
 
@@ -786,8 +791,8 @@ send-and-wait (which registers before typing) or with `wait-output` markers, whi
 `from=buffer` re-finds no matter when they appeared.
 
 The worked shapes are in [recipes.md](reference/recipes.md): Flow 3 (fan out N shell
-workers and gather as each finishes), Flow 3b (the same for claude workers, where the
+workers and gather as each finishes), Flow 4 (the same for claude workers, where the
-send *is* the wait), and Flow 4 (a worker that blocks on a permission prompt).
+send *is* the wait), and Flow 5 (a worker that blocks on a permission prompt).
 
 ### 5.11 List and find yourself
 

skills/codeman/reference/endpoints.md

@@ -666,7 +666,7 @@ whose turn already ended just times out, with or without `fresh`, verified live)
 Register the waiter before the event can happen: send-and-wait does exactly that,
 and `wait-output` markers with `from=buffer` are latched by construction. Never
 fire-and-forget N prompts and then gather signal-waits worker by worker; every
-worker that finishes before its gather is unobservable (see recipes.md Flow 3b).
+worker that finishes before its gather is unobservable (see recipes.md Flow 4).
 
 #### `GET /api/v1/sessions/:id/wait`