Persona composition (type x speciality with stage-skill filtering)

[Ryan-Atkinson87]

Implement persona composition — assembling a runnable persona from type × speciality at render time, so a project gets as many personas as it needs without hand-writing each one (Spec §17.4).

Spec §17.4 (Layer 2 — persona system), §17.3 (specialities filtering mechanism).

Acceptance criteria

• A persona is composed as base type prompt + speciality overlay + matching stage skills, not hand-written (§17.4).
• type is the fixed set planner | implementor | reviewer | qa-reviewer, plus the setup-time tech-lead type (§17.4).
• speciality is open-ended (backend, frontend, accessibility, responsiveness, ui-ux, security, api-contract, …) — adding one is writing an overlay, not a new agent.
• Overlays are structured (metadata + body) like skills, so the same loader/renderer handles them.
• Composition pulls a skill into a persona only if the skill's specialities is unset/neutral or matches the persona's speciality — this is the mechanism that keeps WCAG skills out of a backend review (§17.1, §17.3).
• A composed persona maps to exactly one fresh provider session per task (§17.4, §4.3) — composition produces an instruction set, it does not hold session state.
• Unit tests: implementor×backend excludes accessibility-tagged skills; qa-reviewer×accessibility includes them; an unknown type×speciality pair errors clearly.

Notes

Consumes the skill model from #19. The provider-format output (CLAUDE.md + skill files) is #22; this issue produces the composed, provider-neutral persona content.

Depends on: #19