#1021 extension update/install reports new version while on-disk pulled files stay old

Summary

After updating the pin for a pulled extension, swamp extension update / swamp extension install report the extension as already current at the NEW version, while the files actually on disk under .swamp/pulled-extensions/… remain the OLD version. The only way I found to force the real re-fetch was to delete the cache directories by hand. Filing as a question in case this is expected behavior with a flag I'm missing.

What I saw

On a second machine (Roccinante) syncing a repo whose upstream_extensions.json had been bumped in git:

# upstream_extensions.json (from git) says the new versions:
#   @swamp/s3-datastore  2026.07.02.1
#   @mgreten/github-pr-feed  2026.07.06.1

$ swamp extension install
  → "All extensions up to date."     # but on-disk manifest still 2026.06.30.2 / 2026.05.20.1

$ swamp extension update @swamp/s3-datastore
  → "@swamp/s3-datastore: already up to date (v2026.07.02.1)"   # claims new version…
$ grep '^version:' .swamp/pulled-extensions/@swamp/s3-datastore/manifest.yaml
  version: 2026.06.30.2                                          # …but disk is still old

So the version the CLI reports and the version on disk disagree, and neither install nor update reconciles them — they short-circuit on the lockfile/tracking state without checking (or refreshing) the actual pulled files.

Workaround that worked

rm -rf .swamp/pulled-extensions .swamp/bundles .swamp/datastore-bundles
swamp extension install
  → Installing "@mgreten/github-pr-feed"@"2026.07.06.1"…   # now really re-fetches
# disk manifest now correctly reads 2026.07.02.1 / 2026.07.06.1

After the nuke, the active datastore bundle also correctly contained the new (shard-first) code, so it wasn't just the manifest.

Questions

1. Is this expected — i.e. is the lockfile treated as authoritative and the on-disk files assumed to match, so a divergence (e.g. from a partial earlier pull, or a git-pulled upstream_extensions.json that outran the local cache) isn't detected?
2. Is there a supported --force / --refresh on install/update that re-fetches regardless of tracking state? If so, the docs/--help didn't surface it to me and I reached for rm -rf instead.
3. If not expected: could install/update verify the on-disk manifest version against the pin and re-pull on mismatch, rather than trusting the tracking state?

Minor either way — the workaround is reliable once you know it — but the "reports vNEW while disk is vOLD" divergence is a confusing failure mode (it looks like the update worked when it silently didn't), so wanted it on the record.

Environment

• swamp 20260707.035329.0-sha.84dbdd93 (both machines)
• Multi-repo shared MinIO datastore, per-repo namespaces
• Extensions: @swamp/s3-datastore, @mgreten/github-pr-feed

Thanks!