fix(tooling): build first, then start the app, then list it

The notes had agents start `crafter-build <flag> -r` in the background
and run `crafter-debug ls --wait 60s` straight after. That raced the
build: the first agent to follow them ran the plain build's stub, which
said "no debug build yet" and exited, since the client `ls --wait` needs
is one of the things the debug build compiles, and it polled by hand
until the build was done.

The race came from the order, so the order changes: build with the flag
in the foreground, which ends once the app and the client are built,
then start the app with -r in the background, then `ls --wait`, which
now only waits for what it is for, the app registering. A launcher that
polls for the build instead was tried and dropped: a shell loop that
reruns itself each second, and waits out its whole --wait when no build
is coming at all.

The consumer notes, the client's guide and the README say so, and the
stub and the not-yet-built launcher name the step that was skipped.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

tooling/AGENTS.consumer.md

@@ -4,7 +4,8 @@ This app can be driven while it runs: call its commands, read and set its state,
 
 ### Driving it
 
-- Start the debug build in the background, since it does not exit: `crafter-build <debug flag> -r`.
+- Build with the debug flag first, in the foreground: `crafter-build <debug flag>`. That build also compiles the client `./build/crafter-debug` runs. The first one takes a few minutes.
+- Then start the app in the background, since it does not exit: `crafter-build <debug flag> -r`.
 - From the project directory, use `./build/crafter-debug`:
   - `ls --wait 60s` until it is listed; `status`, `cmds`, `help <command>`, `get '*'`
   - `call <command> key=value ...`, `set <path> <value>`