feat(eliminate-frontend-makefile): task 3.3 - update live documentation (11 files)

Removes every live current-fact reference to src/frontend/Makefile
targets or Makefile-specific fixed paths across 11 docs (steering,
frontend/CLAUDE.md, root CLAUDE.md, deployment docs, and two skill
docs), replacing with the Meson-based equivalents established by
tasks 1-3.2: /xce-build apiserver, meson test --suite apiserver,
direct tests/regression/run.sh invocation.

Round-1 review rejected the first pass: xce-deploy-ha/SKILL.md had
over-corrected by deleting all mention of deploy-ha.sh's still-real
/tmp/apiserver legacy fallback (that script's discovery logic is
unchanged, unlike run-resource-verify.sh's, which genuinely lost its
fallback in task 3.1 -- xce-test-resources/SKILL.md's identical-
looking edit was correct for that reason). Fixed by restoring an
accurate, Makefile-free description of the real fallback at all four
touched sites. Re-reviewed and approved.

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

.claude/skills/xce-deploy-ha/SKILL.md

@@ -37,12 +37,15 @@ disown`) before relying on subagent dispatch for unattended use.
   `cluster.bin` from `src/configs/*.yaml` fresh on every deploy
 - `openssl` must be on `PATH` (provided by `nix develop`) — `deploy-ha.sh`
   generates a fresh self-signed TLS cert/key for every deploy
-- Optional: run `cd src/frontend && make build-server` first if you want an
-  apiserver step (Step 4d) — a separate Go build system from the meson build
-  controller/worker/scheduler share, producing `/tmp/apiserver`.
-  `deploy-ha.sh` never runs this itself; without it, Step 3 simply skips
-  generating `scripts/start-apiserver.sh` (soft-skip, not an error), same as
-  the existing worker/scheduler convention.
+- Optional: run `/xce-build apiserver` first if you want an apiserver step
+  (Step 4d) — the same meson build controller/worker/scheduler share,
+  producing `<build dir>/frontend/apiserver/xce_apiserver`.
+  `deploy-ha.sh` never runs this itself. As a legacy fallback, a binary
+  manually placed at `/tmp/apiserver` is also picked up if the build-dir
+  path is absent (not guaranteed to be the same build generation as
+  `$BINARY`). Without either, Step 3 simply skips generating
+  `scripts/start-apiserver.sh` (soft-skip, not an error), same as the
+  existing worker/scheduler convention.
 - Run `/xce-build worker` so both worker binaries exist in the same build
   dir as `$BINARY`: `xcecd_virtual` (default) and `xcecd` (the real,
   root-gated production daemon). Step 3 auto-picks which one
@@ -162,10 +165,12 @@ This:
   convention. See Step 4c.
 - Also generates `$TOP/apiserver/config/{app.yaml,auth.yaml,rbac.yaml,logger.yaml}`
   and `$TOP/scripts/start-apiserver.sh` **if** a pre-built apiserver binary
-  exists at `/tmp/apiserver` (`make build-server`'s default output path —
-  **not** alongside `$BINARY`, since the apiserver is a separate Go build,
-  not part of this meson build dir) — same soft-skip-with-warning
-  convention as worker/scheduler. See Step 4d.
+  exists — checked in order: first `<build dir>/frontend/apiserver/xce_apiserver`
+  (same build dir as `$BINARY`, produced by `/xce-build apiserver`), then the
+  legacy fixed path `/tmp/apiserver` if the build-dir path is absent (used
+  as-is, with a logged caveat that it's not guaranteed to be the same build
+  generation as `$BINARY`) — same soft-skip-with-warning convention as
+  worker/scheduler if neither exists. See Step 4d.
 - Also **always** generates `$TOP/scripts/start-all.sh`, a combined shortcut
   for Steps 4/4b/4c — see below.
 
@@ -291,9 +296,12 @@ a warning if no wheel exists in the same build dir as `$BINARY`, same as
 ## Step 4d — Start the apiserver (optional)
 
 `deploy-ha.sh` also generates `$TOP/scripts/start-apiserver.sh` **if** a
-pre-built apiserver binary exists at `/tmp/apiserver` (soft-skipped with a
-warning, not a hard error, if missing — see Prerequisites). Start it once at
-least one controller is up, the same way as the worker/scheduler:
+pre-built apiserver binary exists — preferring
+`<build dir>/frontend/apiserver/xce_apiserver` (built via `/xce-build
+apiserver`), falling back to a binary manually placed at the legacy
+`/tmp/apiserver` path if the build-dir one is absent — soft-skipped with a
+warning, not a hard error, if neither exists (see Prerequisites). Start it
+once at least one controller is up, the same way as the worker/scheduler:
 
 ```bash
 "$BASH_BIN" "$TOP/scripts/start-apiserver.sh" &
@@ -450,7 +458,7 @@ If you need a full redeploy (different peers or new binary), run steps 3–5 ins
 | A generated script fails with `bad interpreter` or silently uses the wrong bash | Redeploying with a stale `$BASH_BIN` captured outside `nix develop`, or a shell that shadows `bash` | Re-resolve `BASH_BIN=$(nix develop ./src --command which bash)` right before Step 3 and re-deploy |
 | `scripts/xceadmin ...` (no `--controller`) fails `cannot connect to localhost:9991: Connection refused` | bug-1566, fixed — a wheel built before this fix, or a `deploy-ha.sh` from before it, doesn't export `XCEADMIN_CONTROLLER` | Rebuild (`/xce-build xceadmin --incremental`) and redeploy (Step 3); check `$TOP/scripts/xceadmin` — it should `export XCEADMIN_CONTROLLER="<first --peers candidate>"` before the `exec` line |
 | `scripts/xceadmin` not generated | No wheel in `$BINARY`'s build dir (`deploy-ha.sh` logs a `Warning:`, not an error) | `/xce-build xceadmin` (add `--incremental` if you don't want to lose other already-built binaries in that dir — see `/xce-build`'s SKILL.md), then redeploy (Step 3) |
-| `scripts/start-apiserver.sh` not generated | No binary at `/tmp/apiserver` (`deploy-ha.sh` logs a `Warning:`, not an error) — this is a separate Go build, not part of `$BINARY`'s meson build dir | `cd src/frontend && make build-server`, then redeploy (Step 3) |
+| `scripts/start-apiserver.sh` not generated | No binary at `<build dir>/frontend/apiserver/xce_apiserver` or `/tmp/apiserver` (`deploy-ha.sh` logs a `Warning:`, not an error) | `/xce-build apiserver`, then redeploy (Step 3) — or place a binary at `/tmp/apiserver` (legacy path, not guaranteed to be the same build generation) |
 | Apiserver exits immediately / `Failed to initialize configuration files` | `$TOP/apiserver/config/app.yaml` failed to parse or is missing a required field (e.g. `file_upload.max_size`) — most likely the shipped `src/frontend/apiserver/config/app.yaml` template this is copied from changed shape | Inspect `$TOP/logs/apiserver.log` / `$TOP/apiserver/logs/logger_error.log`; diff `$TOP/apiserver/config/app.yaml` against the shipped template |
 | Apiserver boots but never logs `Backend connection registered` | `app.yaml`'s `backend.peers` doesn't match the controller cluster (stale redeploy), or no controller is up yet | Confirm `$TOP/apiserver/config/app.yaml`'s `backend.peers` matches `$TOP/scripts/start.sh`'s `--peers`; start (or wait for) a controller first |
 | `start-all.sh` reports "no primary election observed... proceeding anyway" | Same causes as `election_timeout` above — no controller became primary within 30s | Check controller logs directly (Step 5); worker/scheduler/apiserver may still fail to connect until a primary exists |

.claude/skills/xce-test-resources/SKILL.md

@@ -105,7 +105,8 @@ script.)
   processes afterward. Tear the deployment down manually afterward (its PIDs
   are visible via `ps`/`pgrep` scoped to `DIR`).
 - Other overridable env vars (all optional, default to this repo's own
-  meson build dir / `/tmp/apiserver`): `$XCE_RESVERIFY_BUILD_DIR`,
+  meson build dir, e.g. `$BUILD_DIR/frontend/apiserver/xce_apiserver` for the
+  apiserver binary): `$XCE_RESVERIFY_BUILD_DIR`,
   `$XCE_RESVERIFY_BIN` (controller), `$XCE_RESVERIFY_SCHED_BIN`,
   `$XCE_RESVERIFY_APISERVER_BIN`, `$XCE_RESVERIFY_XT` (the `xce_test`
   binary), `$XCE_RESVERIFY_PEERS` (defaults to a single-node