Self-hosting CI can't validate ai-meta's own meta.toml with its in-tree binary

[tizz98]

Discovered in #17 (PR #19).

Problem

ai-meta's generated meta-check.yml and ci.yml run the pinned ./meta shim, which downloads the release named by .meta/version and execs it. For the self-hosting repo this is backwards: ai-meta's own meta.toml is validated by an older released binary, so it can only use config fields that release already understands. Adding a field to the schema and using it in the same PR fails CI — deny_unknown_fields rejects the new table under the old binary.

Concretely, PR #19 could not switch .meta/meta.toml to the new [tag] table it introduced; CI failed with:

config error: meta.toml: TOML parse error ... unknown field `tag`

Consequence

Every schema addition needs a multi-PR dance: ship the parser (PR 1, no adoption) → release → bump .meta/version → adopt the field (PR 2). See the #17 adoption follow-up.

Idea

Let the self-hosting repo's CI build and use the in-tree binary (cargo run -- check --strict, cargo run -- ci) instead of the pinned shim, so ai-meta validates its own meta.toml with the binary that defines the schema.

Constraints

• The workflow templates (src/assets/workflows/{meta-check,ci}.yml) are shared by all managed repos, which should keep using the pinned shim. A build-from-source path must be conditional — a self-hosting detection or an explicit opt-in (e.g. a meta.toml flag, or detecting that the repo is the ai-meta crate).
• Must not require hand-editing the generated .github/workflows/* (CLAUDE.md forbids it; meta upgrade would overwrite).

Scope

Framework change to workflow generation (src/assets/workflows/* + the render logic in src/template/src/scaffold). Separate from #17.