feat(skills): fix xce-build/xce-test-ha/xce-deploy-ha subagent dispatch

- xce-build.sh: `controller` component now always builds `controller/xce_test`
  alongside `xce_controller`, in every profile — xce-test-ha needs both
  binaries and previously had to build xce_test as a separate step.
- xce-build/SKILL.md: removed `context: fork` — reproducibly broken for this
  skill (confirmed twice): whenever ARGUMENTS is non-empty, the forked
  subagent never receives a usable task and silently does nothing. Documented
  that this skill should instead always be dispatched via the plain Agent
  tool with a fully-resolved, self-contained prompt (not `context: fork`,
  which failed) — proven to work end-to-end.
- xce-test-ha/SKILL.md, xce-deploy-ha/SKILL.md: replaced the blanket "never
  invoke via subagent" warning with the precise finding — `context: fork`
  (Skill-tool isolation) is the confirmed-broken mechanism (its own teardown
  SIGHUPs the whole controller process group mid-soak/mid-deploy), but
  Agent-tool subagent dispatch is a different mechanism and is safe
  (empirically verified: a `setsid nohup ... & disown` process launched from
  inside an Agent subagent survives that subagent returning, reparented to
  init). Documented both the foreground-blocking and fire-and-forget
  subagent patterns for each skill; xce-deploy-ha additionally flagged that
  its `start.sh &` should gain `setsid` to match the soak driver's stronger
  detach pattern before relying on unattended subagent dispatch.

src/tools/xce-build.sh

@@ -73,7 +73,7 @@ case "$COMPONENT" in
     controller)
         setup_build
         echo "=== Building lib + controller + tests ==="
-        meson compile -C "$BUILD_DIR" xce_controller controller_unit_test
+        meson compile -C "$BUILD_DIR" xce_controller controller_unit_test controller/xce_test
         if [ "$RUN_TESTS" = 1 ]; then
             echo "=== Running controller tests ==="
             meson test -C "$BUILD_DIR" --suite controller --print-errorlogs