Provider-format renderer (compose personas to CLAUDE.md + skill files)

[Ryan-Atkinson87]

Implement the renderer that turns the execution profile + composed personas into the provider-appropriate instruction files written into each repo working copy at run start (Spec §3.4, §17.7). For the MVP this targets Claude: CLAUDE.md + per-persona skill files. Non-Claude (AGENTS.md) output is deferred to Phase 7 but the render path must not assume Claude.

Spec §3.4 (instruction-file generation), §17.7 (rendering), §17.3 (executor/applies_to filtering).

Acceptance criteria

• At run start, per repo: read execution-profile.yaml (execution-profile.yaml schema and fail-fast loader #21) → for each persona, compose (Persona composition (type x speciality with stage-skill filtering) #20) → render to the active provider's format.
• Claude target renders CLAUDE.md (cross-cutting + engine-contract summary) plus the per-persona skill files in Claude Code's expected layout (§17.7 step 3).
• Engine-executor skills are NOT rendered into AI instructions (§17.7 step 4, §17.3) — they are the engine's own spec, surfaced to an AI only at defined hand-back points (e.g. a failing test fed to implement). Verified by test.
• Provider-specific skills (applies_to ≠ neutral) render only for their target provider — a Claude run never emits Codex/Gemini sandbox rules (§17.7).
• Generated files are written into each repo working copy (the instruction file is regenerated, never hand-edited — §17.1, §3.4) and versioned with the project config.
• The renderer is provider-dispatched: a claude renderer exists now; the seam for an agents.md renderer (Codex/Gemini) is present but unimplemented (Phase 7), so adding it is additive.
• Tests: a backend persona render excludes accessibility skills and excludes all executor: engine skills; the Claude output layout is correct; a provider-tagged skill is filtered out for the wrong provider.

Notes

This realises the §17.1 anti-drift goal (one canonical source, generated outputs) and the §17.1 structural guarantee that a backend review session cannot drift into responsiveness/accessibility checks — because those skills are never composed into it.

Depends on: #20, #21