#3288 swamp repo upgrade does not remove the superseded skills it warns about

Summary

Every swamp CLI invocation prints a warning saying 10 superseded skills "can be safely deleted" and instructs the user to run swamp repo upgrade to remove them. Running swamp repo upgrade does not remove them. The warning then fires again on the very next command, so it nags indefinitely and the remedy it names is a no-op.

Reproduction

1. In a repo whose .claude/skills/ still holds the pre-bundle swamp skills, run any swamp command and observe:

[WRN] swamp·cli: "10 old swamp-managed skill(s) can be safely deleted:
swamp-data, swamp-extension, swamp-extension-publish, swamp-issue, swamp-model,
swamp-repo, swamp-report, swamp-troubleshooting, swamp-vault, swamp-workflow.
These have been replaced by the bundled swamp skill.
Run 'swamp repo upgrade' to remove them."

1. Run swamp repo upgrade. It completes successfully:

Upgraded swamp repository: 20260814.234054.0 -> 20260930.234450.0 (tools: claude)
  Skills updated: swamp, swamp-getting-started
  Instructions: unchanged
  Settings: unchanged
  .gitignore: unchanged
  Changed files:
    .swamp.yaml

1. Run any swamp command again — the identical 10-skill warning reappears.

2. Confirm nothing was deleted:

$ ls -d .claude/skills/swamp-* | wc -l
10

All ten directories remain: swamp-data, swamp-extension, swamp-extension-publish, swamp-issue, swamp-model, swamp-repo, swamp-report, swamp-troubleshooting, swamp-vault, swamp-workflow.

Expected

Either swamp repo upgrade removes the directories it identified as safe to delete, or the warning names a command that actually performs the removal.

Actual

repo upgrade reports Skills updated: swamp, swamp-getting-started, writes only .swamp.yaml, and leaves all ten superseded directories in place. The warning is self-referential: it points at a command that does not resolve it.

Impact

Low severity but permanently noisy — the warning prefixes the output of every swamp command, including --json invocations, where it precedes the JSON on stderr. Users who follow the instruction reasonably conclude the upgrade failed.

Possibly related side effect

The same upgrade changed trust resolution: extensions previously installed from the adam and magistr collectives were afterwards reported as untrusted and no longer auto-resolving, requiring swamp extension trust add <collective>. Flagging in case the skill-cleanup and trust-migration steps share a code path; happy to split this into its own report if they are unrelated.

Environment

• swamp CLI: 20260930.234450.0-sha.657fe527
• repo swampVersion: 20260814.234054.0 -> 20260930.234450.0
• platform: darwin 23.6.0 (arm64), zsh
• enrolled tools: claude