fix: reap only our own jobs, and say why a vale probe missed

batch_run ended with a bare wait, which blocks on every background job the
calling shell has, not the ones it started. Harmless for all three current
callers, but a future caller that backgrounds anything of its own would have
batch_run block on it or consume its status. It now records each $! and reaps
exactly those PIDs.

The `wait "$pid" || true` there is load-bearing: unlike a bare wait, wait <pid>
returns the job's status, so without it a single failing job would abort the
set -e caller at the call site -- before run-tests.sh or sync-plugin-content.sh
could read their .status files and print a summary. Status semantics stay in
those files, exactly as before.

check-vale-style-sync.sh's glob probe discarded vale's exit code and output and
decided purely on a grep, so a failed exec, an OOM-killed vale or a full TMPDIR
was indistinguishable from a real glob defect -- both printed "its glob sections
do not cover a path" with no evidence. A flake seen once in this probe could not
be diagnosed afterwards for that reason. The probe now attaches vale's rc and
output: a genuine glob defect reads "vale exited 0 ... in 0 files", a killed vale
reads "vale exited 137; output: <empty>".

That flake was investigated and not reproduced -- 1680 probes across three
contention setups including an offline namespace, all clean -- so nothing is
changed speculatively. The misattribution is worth recording: it was reported
against tests/test-vale-wrap.sh, which never invokes this script; the assertion
belongs to check-vale-style-sync.sh and reaches a log through a different suite.

Also drops the last stale field roster from agent-author's scaffolder. Its
next-steps hint enumerated "(name, description, model, body only)" -- omitting
disallowedTools, and never accurate anyway, since the template marks only
description and the body FILL IN. Its --help carried the inverted form, already
missing six forbidden fields. Both now state the shape rule and point at
field-inventory.md, and a bats case enforces all-or-nothing: name every
allowlisted field or name none, since a partial roster is the shape that goes
stale silently.

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

scripts/lib/batch-run.sh

@@ -32,22 +32,60 @@ batch_jobs_limit() {
 # directly) -- both patterns are preserved as-is by callers, not standardized
 # here, so existing error-handling behavior (including how each pattern
 # interacts with `set -e` in the caller) is unchanged by this extraction.
+#
+# batch_run waits ONLY on the PIDs it started, never with a bare `wait`. A bare
+# `wait` blocks on every background job of the calling shell, so a caller that
+# backgrounds anything of its own would (a) have batch_run block until that
+# unrelated job finished and (b) have that job reaped here, with its exit status
+# consumed by the wrong `wait` -- leaving the caller's later `wait $pid` to fail
+# with "not a child of this shell". None of the three current callers backgrounds
+# anything else, so this was latent rather than live, but it was an undocumented
+# constraint on every future caller. Recording each `$!` and waiting on it by PID
+# removes the constraint instead of documenting it.
+
+# batch_wait_pids [<pid> ...]
+#   Reaps exactly the given PIDs and always returns 0.
+#
+#   The `|| true` is load-bearing, not defensive noise: unlike a bare `wait`
+#   (which is unconditionally 0), `wait <pid>` returns that job's exit status, so
+#   without it a single failing job would make batch_run return nonzero and abort
+#   its `set -e` caller at the call site -- before the caller could read the
+#   .status files and print its own summary. Status semantics stay entirely in
+#   the .status files, exactly as before.
+#
+#   `${@+"$@"}` rather than a bare `"$@"`, for the same reason every `${arr[@]}`
+#   in this repo carries the `${arr[@]+...}` guard. Bash 4.4 is what relaxed
+#   `set -u` for an all-empty `@`/`*` expansion (CHANGES, 4.4 "New Features in
+#   Bash" 3a); 3.2 predates that relaxation, and no bash on a modern machine can
+#   reproduce the abort, so the guarded spelling is asserted rather than tested.
+#   Zero args is a normal path here, not an edge case: the trailing call receives
+#   an empty list whenever the job count divides evenly into the concurrency cap.
+batch_wait_pids() {
+  local pid
+  for pid in ${@+"$@"}; do
+    wait "$pid" || true
+  done
+}
+
 batch_run() {
   local scratch_dir="$1"
   shift
-  local jobs_limit running key cmd
+  local jobs_limit running key cmd pids
   jobs_limit="$(batch_jobs_limit)"
   running=0
+  pids=()
 
   while [[ $# -gt 0 ]]; do
     key="$1" cmd="$2"
     shift 2
     (eval "$cmd") >"$scratch_dir/$key.log" 2>&1 &
+    pids+=("$!")
     running=$((running + 1))
     if [[ $running -ge $jobs_limit ]]; then
-      wait
+      batch_wait_pids ${pids[@]+"${pids[@]}"}
+      pids=()
       running=0
     fi
   done
-  wait
+  batch_wait_pids ${pids[@]+"${pids[@]}"}
 }