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/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`