Production adoption: make Azazel a centrally versioned dependency

Problem

The current adoption path still encourages projects to copy Azazel's build.zig, schema, exporter, and generator files into the project. That weakens one of Azazel's strongest reasons to exist: absorbing std.Build API churn once in Azazel instead of redistributing that maintenance burden into every consumer repository.

Goal

Define an installation/bootstrap shape where a consuming project pins one Azazel release/revision and keeps only its project-specific model locally.

A normal upgrade should change the Azazel pin, not require manually copying a new executor/generator bundle into every project.

Acceptance criteria

• A fresh external Zig project can pin Azazel through a documented versioned mechanism.
• The consuming repo owns its project.cue and project-specific export/config, but the compatibility engine is sourced from the pinned Azazel version.
• azazel check, azazel gen, and azazel build use the pinned implementation rather than a copied stale CLI/generator.
• Upgrading the pin is sufficient to pick up a future std.Build compatibility fix.
• A minimal external fixture is built in CI from a clean checkout to prove the adoption path.
• Documentation distinguishes vendoring as an explicit fallback rather than the primary installation model.

Start with the documented adoption path and the azazel check, azazel gen, and azazel build entry points. Design a versioned pin that supplies the compatibility implementation while leaving project.cue and project-specific export/config in the consuming project. Add a minimal external fixture built in CI from a clean checkout, and document vendoring as a fallback.