test(xce-harness-component): verify all downstream workflows end-to-end

Validation-only task, no source changes. Ran all four downstream
workflows (xce-test-ha, xce-deploy-ha, xce-test-multihost,
xce-test-resources) against a genuinely harness-absent, otherwise
fully-built dir -- established by explicitly removing harness/xce_test
immediately before each invocation, since sibling-component builds
(controller, worker, scheduler) kept transitively resurrecting it via
the same Meson mechanism task 4.3 documented.

xce-test-ha, xce-test-multihost, xce-test-resources all fail fast with
the documented clear, actionable "run /xce-build harness" message
before any expensive deploy work. xce-deploy-ha has zero harness
dependency (grep-verified) and deployed a real 3-node HA cluster
successfully with harness absent; its documented soft-skip path was
also exercised. All processes and deploy directories cleaned up and
independently re-verified by review.

This completes all 16 tasks of the xce-harness-component spec.

Task 4.4 of xce-harness-component.

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

.kiro/specs/xce-harness-component/tasks.md

@@ -90,7 +90,7 @@
   - Observable: each of the three build invocations produces exactly the binaries described above, and the controller-only build's explicit `meson compile` step is confirmed (via build-log inspection) to never name `xce_test`
   - _Requirements: 2.1, 2.2, 2.4_
   - _Depends: 3.1_
-- [ ] 4.4 Verify every downstream workflow from a clean build state
+- [x] 4.4 Verify every downstream workflow from a clean build state
   - Run the HA soak, local HA deploy, multi-host verification, and resource-value verification workflows starting from a build directory where the harness has never been built
   - Observable: none of the four workflows fails with a raw/unrelated error; each either succeeds after building the harness itself or reports the expected clear, actionable message
   - _Requirements: 5.1, 5.2, 5.3, 5.4_
@@ -103,6 +103,7 @@
 - **Task 1.1 gotcha**: a meson `custom_target` command's `@INPUT0@`/`@OUTPUT0@` tokens expand to build-root-relative paths, but a symlink's target string is resolved relative to the *symlink's own directory* at dereference time, not the invocation cwd or the string's own reference frame — using `@INPUT0@` directly as an `ln -sf` target from a different subdirectory produces a broken link. Use an explicit `../`-relative (or absolute) path instead.
 - **Build dir note**: this repo's default build dir resolves to `src/xce.build/` (relative to `src/tools/xce-build.sh`'s own cwd), not a bare `xce.build/` at the repo root.
 - **Task 4.1**: Confirmed behavioral parity conclusively — found a genuine pre-relocation binary (`src/build.dbg/controller/xce_test`, predates commit `cf55d691` by 3 days) and byte-diffed its `--help`/`--usage`/piped-REPL output against the harness-built binary: identical (only `--version`'s embedded build-hash/timestamp differs, as expected). Real, non-blocking follow-up found (out of this spec's boundary, pre-scoped by requirements.md's Adjacent Expectations for the `xce-test-rc-file`-owned one): `src/controller/testsuite/test_rcfile_integration.sh` and `clean_failover_preservation.sh` (the latter actually belongs to `ha-term-safety` task 5.2, not one of the three named xce-test-* specs) both hardcode a stale default binary path (`src/xce.build/controller/xce_test`) and the latter's failure message still says "run /xce-build controller" — should be repointed to `src/xce.build/harness/xce_test` by whoever owns each script next.
+- **Task 4.4 (final task)**: verified all four downstream workflows against a genuinely harness-absent, otherwise-fully-built dir, including a real 3-node HA cluster deployment for `xce-deploy-ha`. All pass. Extended task 4.3's finding: `worker)` and `scheduler)`'s `xce-build.sh` cases also run `meson test`, so they too transitively resurrect `harness/xce_test` via the same mechanism (`apiserver)` does not, since it only runs `go test`) -- same accepted-limitation status as task 4.3, no new decision needed. Found one more pre-existing, out-of-boundary stale doc claim worth a quick follow-up sometime: `.claude/skills/xce-build/SKILL.md:37` still says "controller always builds xce_test too... in every profile" (false since task 3.1).
 - **Task 4.3**: found a real, deterministic Requirement 2.2 conflict, not a flake — under the default `asan` profile, `/xce-build controller`'s `meson test --suite controller` step transitively rebuilds `harness/xce_test` on disk, because Meson's test-runner rebuilds every registered test's build-order dependencies project-wide before filtering by `--suite`, and `harness_unit_test` (task 2.1) depends on `xce_test`. Traced precisely via build-log line analysis (explicit `meson compile` step: 209 steps, clean; subsequent `meson test` step: 844 steps, resurrects it) -- this is why task 3.1's own validation missed it: it checked the old `controller/xce_test` path (correctly absent), not `harness/xce_test` (the path that actually gets touched). User decision 2026-09-14: accept as a documented Meson limitation and narrow Requirement 2.2's wording to what the build system directly controls (its own explicit compile-target list), rather than auditing every component's test-target list (non-trivial -- controller's own suite already has 4 small test binaries not in its own explicit compile list, relying on this exact same auto-rebuild) or weakening `harness_unit_test`'s build-order dependency (task 4.2 verified load-bearing). requirements.md/design.md updated accordingly; logged as bug (not-fixed, accepted) for the record.
 - **Task 3.7**: Major Task 3 (Integration) is now fully complete. Task 3.6's review round caught a real doc-consistency miss (a partial fix left a contradicting stale claim elsewhere in the same file); the lesson (full end-to-end file re-read, not just the two named spots) was applied successfully in 3.7 and independently confirmed by review. Non-blocking follow-up noted for a future pass: `structure.md` line 92's generic "`test.c` provides the test runner harness" line is doubly stale (controller's runner is `controller_test.c`, harness's is `harness_test.c`) and also coincidentally collides with `src/harness/test.c`, which is real production code (xce_test's REPL entry point), not a test runner — worth a one-line correction sometime, out of this spec's boundary.
 - **Task 2.2**: Major Task 2 (Core) is now fully complete — all 5 harness test binaries exist under `suite: 'harness'` (4/20/5/12/132 tests, all green), controller's suite is fully clean at 1199 tests. Minor non-blocking cleanup found for a future pass: `src/controller/meson.build:211`'s `struct2json_dep` comment still cites `test_listfmt_json.c` (relocated to harness in task 2.1) as a consumer, and its own dependency may now be unused in `controller_unit_test_deps` — worth checking whether it can be dropped entirely once someone audits it.