chore(build): make xce-build.sh self-wrap into nix develop

meson/ninja/capnp/Go only exist inside the hermetic nix dev shell, but
xce-build.sh never entered it itself -- the /xce-build skill documented
wrapping every invocation in `nix develop ./src --command ...` by hand,
so a bare `bash src/tools/xce-build.sh ...` (run directly instead of
through the skill) failed opaquely with "meson: command not found". This
was a recurring, previously-logged gap that resurfaced again today mid
bug-1789 verification.

The script now checks IN_NIX_SHELL at the top and re-execs itself under
`nix develop` if unset, so every caller -- the skill, a bare invocation,
CI, a human at a terminal -- gets it automatically. A nested call (already
inside the shell) is a no-op past that check. README.md's daily-develop
section updated to match; the old "or use nix develop --command" example
is now redundant and removed.

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

.wolf/cerebrum.md

@@ -230,3 +230,4 @@
 - **(2026-08-26, xce-test-rc-file task 3.1) `xce_test`'s `cmd_set(argc==1)` (`set` with no args) is the generic, no-live-cluster-required readback for ANY setting** (`test.c:3684`, format `"%-12s:%s default: %s\n"`, `KVAL()` prints `"<not set>"` for a NULL current value) — the right primitive for any integration test that needs to observe an rc-file/`set`-driven setting change (e.g. `masters`) without a live controller connection. Don't hardcode the exact column padding when grepping its output (fragile) — extract via `sed -E 's/^masters[[:space:]]*:(.*) default:.*/\1/'` (greedy `(.*)` correctly captures the embedded-space `"<not set>"` sentinel too, since there's only one literal `" default:"` substring per line to anchor against).
 - **(2026-08-26, xce-test-rc-file task 3.1) `xce_test` uses `libedit`'s `readline()`/`isatty(STDIN_FILENO)`-gated `g_interactive`, so a genuine interactive-mode integration test needs a REAL pty, not a piped stdin** — confirmed working via a small embedded Python `pty.fork()` driver (write commands to the master fd with a short settle delay after each, drain with `select()`, detect child exit via non-blocking `waitpid`, `os.waitstatus_to_exitcode()` for the real exit code). Same technique task 2.2's own implementer used for manual verification; this task turned it into a reusable scripted harness. The prompt itself (`fill_prompt`, top-level context) renders as literal `"xce>"` — grepping for that substring in the pty transcript is a good "this really was a TTY session, not a piped fallback" sanity check, distinct from the actual assertion under test.
 - **A `.kiro/specs/*/tasks.md` checkbox count (`- [ ]` vs `- [x]`) is NOT reliable at face value when it includes section-HEADER checkboxes ("- [ ] N. Some phase name") — a spec whose every N.M subtask is `[x]` but whose parent `- [ ] N.` header was never flipped reads as "in progress" when it is actually 100% done.** (2026-09-03, cross-spec audit) Recurred a second time after the first fix (`5c82ad0b`, 2026-08-24, 5 specs): `scheduler-sim-eager-reconciliation` looked like "6/9, stalled since Aug 22" by a naive checkbox count, but all 3 "unchecked" items were section headers whose children (1.1/1.2/2.1/3.1/3.2/3.3) were already all `[x]`, with a `task 3.3 full regression confirmation` commit proving genuine completion on 2026-08-27. `worker-rejoin-resync` was the same drift the other direction (28/28 real tasks incl. headers all `[x]`, but `spec.json.phase` itself never advanced past `tasks-generated`). **Before reporting any spec as "stalled" or "N/M done," check headers and children SEPARATELY (`grep -E '^\s*-\s*\[ \]\s*[0-9]+\.'` for unchecked headers vs `^\s*-\s*\[ \]\s*[0-9]+\.[0-9]'` for unchecked subtasks) and cross-check `spec.json.phase`/`updated_at` against the tasks.md file's own git log — a low, stale-looking checkbox ratio and a phase field that hasn't moved are both metadata that can independently lag the real state, not just one signal.**
+- **(2026-09-07, bug-1789) When a per-job "how much of resource X does this job want" value needs to reach a NEW consumer (e.g. a limit-evaluation function) that only sees a *subset* of the data (`ctx->alloc_req.shared`, filled only with genuinely-`XCE_RESF_GLOBAL`-flagged resources), do NOT "fix" it by writing that value into the shared/global request vector too, even if an existing sibling code path two lines above already branches on the same condition and looks like it's establishing the pattern to mirror.** `sched_fill_limit_requests()` (resource.c) needed a GLOBAL limit's underlying `"slots"` resource want, which seqjob/parjob's `prepare_allocation` hooks always staged into `ctx->alloc_req.host` (never `.shared`, since `"slots"` is deliberately per-host-only and excluded from `calc_wanted_global_resvals()`). The natural-looking fix — branch that one unbranched store by `ctx->worker == NULL` to mirror the `calc_wanted_*_resvals()` if/else two lines above it — compiled, passed 2 new targeted regression tests, and then broke 6 *other* previously-green tests (seqjob/parjob dispatch going from DISPATCH to PEND): `ctx->alloc_req.shared` is DUAL-PURPOSE — also read by `sched_check_shared_satisfy()` against `sched->core.sharedInst`, the genuinely-global capacity pool, which has no entry for `"slots"` at all, so injecting a spurious "wants slots" entry there made EVERY job's general resource-satisfy check spuriously fail, not just limit-scoped ones. **General lesson: before writing a new value into a shared/multi-purpose vector to fix ONE consumer, grep every OTHER reader of that same vector and confirm none of them will now see a value they don't know how to interpret — prefer teaching the ONE actually-broken consumer to read the value from its true source (here: `ctx->nslots`, already computed correctly earlier in the same call) over widening what a shared vector carries.** Caught only by re-running the full test suite after the first fix, not by reasoning about the change in isolation — a good reminder that "just mirror the adjacent branch" is not a substitute for checking a shared data structure's OTHER readers. **Follow-up refinement (same bug, user-prompted):** the eventual read-side fix initially special-cased by resource NAME (`strcmp(vres->res->name, "slots")`) — correctly called out as unreliable, since it silently fails to generalize to any future per-host resource not literally spelled "slots". Replaced with the resource's own `XCE_RESF_GLOBAL` flag (the same flag `calc_wanted_global_resvals()`/`calc_wanted_host_resvals()` already dispatch on) to pick `alloc_req->shared` vs `.host` — before hand-rolling a name/string-based special case for "which bucket does this belong in," check whether the codebase already has a flag/enum driving the identical classification elsewhere and reuse it.