Skill body edits aren't in version history and Rollback doesn't undo them

[Sheldenshi]

Summary

Outcome-driven skill edits (ADR docs/adr/skill-learning-from-outcomes.md) modify a skill's SKILL.md body, but the version-history and rollback machinery operate on the legacy CRUD fields only. As a result a body edit bumps the version number but its change isn't recorded in history, and the Skills-page Rollback button does not undo it.

Details

• SkillVersion (src/types.ts) = { version, updatedAt, description, trigger, steps, requiredTools, requiredPermissions } — no body. So previousVersions can't represent a body edit; the web Skills page (web/src/app/skills/page.tsx) shows the prior legacy fields, not the prior body.
• rollbackSkill (src/capabilities/skills.ts:313) restores description/trigger/steps/requiredTools/requiredPermissions, bumps version, and does not touch body or rewrite the on-disk SKILL.md.
• Outcome-driven edits apply via installSkillFromBody (rewrites the on-disk SKILL.md body + reloads). The correct revert is revertImprovement (re-installs the stored baseBody), which is not exposed via HTTP/CLI/UI.

Consequence

After an approved body edit (e.g. version 1→2), clicking Rollback in the web UI:

1. reverts the legacy fields in state (not what a filesystem skill's model actually reads — it reads body),
2. bumps the version again,
3. leaves the on-disk SKILL.md body unchanged (still edited), so the next loadSkillsFromDisk re-reads the edited body.

Net: the user thinks they rolled back, but the skill's actual content is unchanged. The control is misleading.

Repro

1. Approve an outcome-driven edit-mode ImprovementProposal for a user skill (or POST one to /api/improvements with payload.mode:"edit" and approve it). The SKILL.md body changes, version → 2.
2. Open the Skills page → previousVersions shows no body change.
3. Click Rollback → version bumps but the body is unchanged on disk; a reload keeps the edit.

Fix direction

• Carry body in the version snapshot (extend SkillVersion with an optional body, or a parallel body-history), and make rollbackSkill body-aware and rewrite the on-disk SKILL.md for filesystem skills (so a reload doesn't clobber it) — OR
• Route rollback of an outcome-driven edit through revertImprovement (re-install baseBody) and disable/relabel the legacy Rollback button when the latest change was a body edit.
• Either way: expose a correct revert via POST /api/improvements/:id/revert and reflect body history in the UI.

Related: #389 (Skill review experience) depends on a correct body history + revert.