What happened?

pi install <pkg>@<newtag> reports Installed but does not checkout <newtag> when the package's clone already exists in ~/.pi/agent/git/. Refs fetch through (the new tag shows in git for-each-ref), but the working tree's HEAD stays at the previously installed commit. Pi loads the stale source on next startup.

Related: pi update does not re-resolve packages entries against their pins, so bumping a pin in settings.json never lands without an explicit pi install. Combined with the no-op above, a pinned package can stay on its first-resolved commit forever despite both commands reporting success.

Same silent-failure shape as #4811 but a different code path (installer, not compaction).

Steps to reproduce

Pre-condition: settings.json packages references a tagged git package that is already cloned from a prior session.

git -C ~/.pi/agent/git/github.com/vieko/bonfire describe --tags
# v7.2.0

pi install 'git:github.com/vieko/bonfire@v7.2.1'
# Installing git:github.com/vieko/bonfire@v7.2.1 ...
# Installed   git:github.com/vieko/bonfire@v7.2.1

git -C ~/.pi/agent/git/github.com/vieko/bonfire describe --tags
# v7.2.0          ← still on the old commit despite "Installed"

git -C ~/.pi/agent/git/github.com/vieko/bonfire for-each-ref refs/tags/ \
  --format='%(refname) %(objectname:short)' | grep v7.2.1
# refs/tags/v7.2.1 79591ec   ← ref was fetched, never checked out

Workaround: rm -rf ~/.pi/agent/git/<host>/<owner>/<repo> && pi install '...'. A fresh clone goes through clone+checkout.

Expected behavior

After pi install ...@v7.2.1, the working tree is at refs/tags/v7.2.1. git describe returns v7.2.1. Next Pi startup loads v7.2.1's source.

pi update either re-resolves packages entries against their pins, or prints a note that it doesn't (so users know they need pi install for a pin bump).

Version

0.75.4