execution-profile.yaml schema and fail-fast loader

[Ryan-Atkinson87]

Define and load execution-profile.yaml — the per-project Layer-3 file that declares which personas a project instantiates and how stages route. It is distinct from project.yaml (human-authored config, #4) and has a different change cadence: regenerated on structural change, not hand-edited (Spec §17.5).

Spec §17.5 (Layer 3 — project execution profile), §17.2 (three-layer overview).

Acceptance criteria

• A Pydantic schema for execution-profile.yaml declaring, per Spec §17.5: the instantiated personas (type × speciality list); per-stage executor confirmation where it differs from default (AI persona vs engine); routing (which persona handles which repo/role; which QA specialities apply); any project-specific skill overrides/additions.
• A fail-fast loader validating the profile at startup, consistent with the project.yaml loader pattern (project.yaml Pydantic schema and fail-fast loader #4) — a malformed profile errors before any wave begins.
• The schema models both Spec §17.5 example shapes: the Trive multi-persona shape (backend/frontend/admin + accessibility/responsiveness/ui-ux QA) and the backend-only shape (planner, implementor×backend, reviewer×backend, reviewer×security, no UI QA).
• Cross-references resolve: persona type×speciality entries are valid against the fixed type set and known specialities; skill-override ids resolve against the canonical set (Canonical skill model and loader (metadata + body; tool-base + per-project) #19).
• The file is documented as generated output (by Tech-lead profile-generation session (propose execution-profile, human-confirm before write) #23), not hand-edited — but a hand-written profile still loads and validates.
• Unit tests: valid Trive-shape profile, valid backend-only profile, invalid persona type, unknown stage, malformed YAML.

Notes

This issue is the schema + loader only. Generation of the profile by the tech-lead session is #23; consumption by the renderer is #22.

Depends on: #1, #4