fix(xce-build skill): dispatch builds via Bash run_in_background, not Agent subagent

Replaces the "always dispatch via the Agent tool" instruction with a
direct Bash-tool run_in_background pattern, following the harness's
own task-notification mechanism instead of trusting a subagent's
self-reported "I'll report back."

Confirmed broken 2026-09-03: a general-purpose subagent given the
exact "wait for it, do not background it" instruction redirected the
build to a log file, announced it would report back once finished,
and returned immediately with no result -- its own Agent-tool call
showed completed with nothing to relay. The harness did eventually
deliver a second, fuller notification for that same subagent several
minutes later, but a controller cannot rely on that arriving, per the
prior "fork claimed will report back, never reachable in a new
session" incident already logged in .wolf/cerebrum.md.

The new pattern (proven reliable twice this session: a full `all
debug` build and a `controller` ASAN rebuild) runs the resolved
command directly with Bash's own run_in_background, waits for the
harness's real completion notification, then reads only the log's
tail plus a targeted error grep -- keeping context usage low without
depending on a subagent's compliance.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YAWMhfRJFnmmnG8h97yUDd

.claude/skills/xce-build/SKILL.md

@@ -27,11 +27,21 @@ nix develop ./src --command bash src/tools/xce-build.sh <component> <profile> <b
 
 e.g. for `/xce-build controller`: `nix develop ./src --command bash src/tools/xce-build.sh controller`. For `/xce-build xceadmin --incremental`: `nix develop ./src --command bash src/tools/xce-build.sh xceadmin --incremental`.
 
-## Always dispatch the build via the Agent tool
+## Run the build via Bash `run_in_background`, not an Agent-tool subagent
 
-Do not run the `nix develop … xce-build.sh` command inline in the current session's Bash tool. Instead, on every invocation of this skill, launch a subagent with the Agent tool, giving it a fully self-contained prompt: repo working directory, the exact resolved command (component/profile/build_dir already substituted — do not make the subagent re-parse ARGUMENTS itself), what the command does, and what to report back (build success/failure, compiler errors, the meson test Ok/Fail summary line, and confirmation the expected binaries were freshly rebuilt with fresh mtimes). Wait for it (do not background it — the build is synchronous and finishes in well under this session's turn budget) and relay its report.
+**Do not dispatch the build to an Agent-tool subagent** (confirmed broken 2026-09-03: a general-purpose subagent given this exact instruction redirected the build to a log file, announced "I've kicked off the build in the background... I'll report back once it finishes," and returned immediately — its own Agent-tool call then shows as `completed` with no build result. That "I'll report back" is not reliable: the parent has already regained control and cannot assume a second notification is coming. In this occurrence the harness *did* eventually deliver a second, fuller notification for the same subagent several minutes later, but a controller cannot bank on that — a near-identical pattern in an unrelated cross-session case never came back at all, per the OpenWolf cerebrum warning "A fork/subagent dispatched in a prior session that claimed 'build/tests in progress, will report back' is NOT reachable in a new session." A model instructed in plain English to "wait, don't background it" backgrounding it anyway is the actual failure mode — a differently-worded subagent prompt is not a reliable fix for that).
 
-This is deliberately a plain Agent-tool dispatch, not `context: fork` — that frontmatter field reproducibly failed to thread a non-empty ARGUMENTS payload into the forked subagent (see above), whereas an explicit, self-contained Agent prompt has no such dependency and is proven to work.
+Instead, run the resolved command directly with the **Bash tool's own `run_in_background: true`**, from the current session, and let the harness's own task-notification mechanism — not a subagent's self-report — tell you when it's done. This has been empirically proven reliable in this exact repo (2026-09-03: both a full `all debug` build and a `controller` ASAN rebuild were driven this way, and each genuinely blocked until real completion).
+
+```bash
+nix develop ./src --command bash src/tools/xce-build.sh <component> <profile> <build_dir> [--incremental] \
+  > <scratchpad>/xce-build-<component>-<profile>.log 2>&1; \
+  echo "EXIT_CODE=$?" >> <scratchpad>/xce-build-<component>-<profile>.log
+```
+
+Call this once with `run_in_background: true` (substitute the resolved component/profile/build_dir and a scratchpad log path first — do not make anything downstream re-parse ARGUMENTS). Then stop and wait; do not poll, sleep-loop, or call `ScheduleWakeup` — the harness delivers a `<task-notification>` the moment the process exits, exactly like any other backgrounded Bash command. When it arrives, read the log's **tail** (e.g. `tail -30`) plus a targeted `grep -nE "error:|FAILED|undefined reference|Traceback"` rather than the whole log, to get the meson test Ok/Fail summary line and any failures without pulling the full (often thousands-of-lines) compiler output into context. Then `ls -la` the expected output binaries to confirm fresh mtimes, the same verification this skill has always asked for — just performed directly instead of trusted from a subagent's claim.
+
+This is deliberately not `context: fork` either — that frontmatter field reproducibly failed to thread a non-empty ARGUMENTS payload into a forked subagent (see above). Running the resolved command directly via `Bash`/`run_in_background` sidesteps both failure modes: there is no subagent in the loop to either drop the ARGUMENTS payload or silently background-and-return.
 
 ## Installing the xceadmin wheel elsewhere