Landed retro patches are silently reverted on the next run

[n1arash]

Summary

A landed retro patch is silently reverted on the very next run. vendored.install() runs at the start of every pipeline run, treats the landed (higher-version) patch as skill drift, and repairs it back to the packaged baseline version. This defeats the entire point of the flywheel.

Evidence (dogfood campaign)

• The patch-gate validation landed a foreman-tdd patch v3→v4: .foreman/SKILL_CHANGELOG.md records skill:foreman-tdd → v4 and the proposal is approved/sealed.
• After the next pipeline run (the F1 payoff), the installed SKILL.md is back to v3 and the patch text is gone (grep -c Handoff-first = 0).
• Mechanism: Pipeline.ensure_skills_installed() (pipeline.py:84) and scheduler.py:204 call vendored.install() at the start of every run, overwriting the landed v4 with the packaged v3.

Why it matters

Even if retro produced a good proposal and a human approved + benched it, the improvement evaporates on the next build. It also confounded the campaign's payoff run: the F1 re-run executed with the patch already reverted, so it never tested the patched skill.

Proposed fix

Make vendored.install() version-aware: never downgrade or overwrite an installed skill whose foreman_skill_version is ≥ the packaged one. A landed retro patch is, by construction, a higher version and must outrank the packaged baseline.

Acceptance criteria

• vendored.install() compares foreman_skill_version and refuses to overwrite an installed skill that is newer-or-equal to the packaged one.
• A landed v4 patch survives a subsequent pipeline run (changelog + SKILL.md both still v4).
• Genuine drift (installed version older than packaged, or hand-edited at the same version) is still repaired.
• Regression test: land a patch, run install, assert the patch persists.

Source: dogfood/ITERATION_REPORT.md BLOCKER-2b; dogfood/FLYWHEEL.md post-hoc correction.