#712 swamp repo upgrade should check git status and commit (or surface) the files it changes

Problem

A swamp repo upgrade rewrites repo-managed files but leaves them as silent, uncommitted working-tree changes. In our repo the 20260605→20260619 upgrade touched:

• .swamp.yaml (swampVersion + upgradedAt bumped)
• the bundled .claude/skills/* — ~10 granular skills (data/model/workflow/vault/extension/issue/repo/report/troubleshooting/extension-publish) consolidated into a single swamp skill (+ ollama)
• CLAUDE.md Rules/Skills sections (references retargeted to the consolidated skill)
• extensions/models/upstream_extensions.json

That was ~93 files / ~1.7k changed lines landing with no notice. In a repo with ongoing work, this drift piles up and gets conflated with the user's own changes — easy to miss, to accidentally stage alongside unrelated work, or to discard. There's no post-upgrade summary and nothing ties the changes to the upgrade that produced them.

Proposed solution

After swamp <repo> upgrade completes, check git status on the paths swamp manages and either:

1. (default) print a summary of the managed files it changed, or
2. (with a flag, e.g. --commit) make a single scoped commit of just the upgrade-managed files — message like chore: swamp repo upgrade <old>→<new> — leaving the user's unrelated changes untouched.

swamp already records gitignoreManaged: true in .swamp.yaml, so it knows which paths it owns; the commit/summary can be scoped to exactly those, never the user's files.

Alternatives

• Post-upgrade summary only (no commit) — minimal, still solves the "silent drift" surprise.
• A swamp repo status / --dry-run that reports pending swamp-managed drift.
• Leave as-is and document that an upgrade should be committed immediately (weakest).

Environment

swamp 20260619.192031.0-sha.00083fc5