Provide a docs-toolbox build script for consuming projects

[dieterbaier]

Problem

Consuming projects have no guided way to run the vendored architecture
validators, generators, and documentation render inside the reproducible
docs-toolbox image:

• skills/bootstrap-project/SKILL.md mentions neither build.sh nor
  docs-toolbox.
• The example/ consuming project ships no build script.
• The README documents build.sh only for the toolkit itself; the "Consuming
  This Toolkit From a Project" section lists schemas/templates/scripts and the
  agent-adapter generator to copy, but no build runner.

So each project reinvents how to invoke the toolchain (and often runs it on an
unpinned host toolchain), which undercuts the reproducibility guarantee.

Change

• Add templates/scripts/build.sh — a generic, parameterizable docs-toolbox
  task runner a project copies to its root. Tasks: validate, generate,
  adapters, check-adapters, build, all, clean. Container-by-default
  (Docker/Podman) against the pinned docs-toolbox image, with a
  DOCS_TOOLBOX_LOCAL=1 host fallback; SOURCE_DOC and DOCS_TOOLBOX_IMAGE
  are overridable. It wraps only the docs toolchain and explicitly leaves
  application builds (JDK/Gradle, npm, …) on their own tooling.
• Reference it from the bootstrap skill — generator-support list,
  Reference-Don't-Copy copied-tooling list, and the complete-bootstrap list.
• Reference it from the README — "What a project copies vs. references" and
  a new wiring step.

The guidance mirrors the existing build-agent-adapters.js pattern: copy the
parameterizable templates/scripts/ version, not the toolkit's own root
build.sh, which is wired to the toolkit itself.

Notes / possible follow-ups

• This documents and templatizes the script; it does not yet make the
  bootstrap-project flow copy it automatically, nor add it to example/.
  Happy to extend to either if preferred.
• Derived from real use: a consuming project (event-processing-lab) needed this
  and a hand-written copy of exactly this script to wire validation + a GitHub
  Pages publish.

🤖 Generated with Claude Code

[dieterbaier]

Die Richtung passt: Der generische Runner schließt eine echte Lücke zwischen vendortem Toolkit und reproduzierbarer Ausführung im Projekt. Die Container-/Local-Trennung, explizite Image-Version und Trennung vom Application-Build sind sauber. Ich habe einen Absicherungspunkt kommentiert: Der neue ausführbare Templatepfad wird aktuell weder im Beispiel noch durch einen gezielten Test ausgeführt. Für ein Bootstrap-Artefakt mit Shell-, Docker- und Argumentweiterleitungslogik sollte wenigstens Syntax und Local-Mode-Verhalten in CI geprüft werden.

[dieterbaier]

Der neue Runner ist produktive Bootstrap-Logik, wird in diesem PR aber offenbar nur dokumentiert und nicht selbst getestet. Bitte mindestens sh -n templates/scripts/build.sh sowie einen kleinen Test des Local-Mode-Dispatchs (validate/generate/check-adapters, gern mit Stub-Kommandos in PATH) in CI aufnehmen. Noch besser wäre, das example/ mit einer wörtlichen Kopie des Templates auszustatten und dort check/build auszuführen. Sonst kann der Templatepfad unbemerkt brechen, während die toolkit-eigene build.sh weiterhin grün bleibt.

[dieterbaier]

Addressed in f3f6366: added test/build-sh-template.test.mjs — asserts sh -n templates/scripts/build.sh and that local-mode dispatch (validate/generate/check-adapters) invokes the expected vendored tool via stub ruby/node on PATH. Wired into the test-js task and README, so ./build.sh test and CI run it (14 JS tests pass). Left the 'literal copy in example/' idea out for now to keep the PR focused — happy to add if you'd like.

[dieterbaier]

Nachprüfung der Änderung: Der neue Test deckt den zuvor fehlenden Templatepfad sinnvoll ab (sh -n plus Local-Mode-Dispatch für validate, generate und check-adapters). Die aktuelle CI ist grün. Keine weiteren Findings.