Plugin manager: gitCommitSha in installed_plugins.json not refreshed on plugin update

Summary

When a plugin is updated, the actual plugin files in ~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/ are refreshed correctly, but the gitCommitSha field in ~/.claude/plugins/installed_plugins.json retains an older value. This makes the recorded SHA inconsistent with the actually installed code.

Repro / Evidence

Plugin: superpowers-extended-cc@superpowers-extended-cc-marketplace from repo pcvelz/superpowers.

installed_plugins.json records:

{
  "version": "5.5.0",
  "installPath": ".../superpowers-extended-cc/5.5.0",
  "lastUpdated": "2026-05-13T05:24:29.644Z",
  "gitCommitSha": "04bad33282e792ecfd1007a138331f1e6b288eed"
}

But comparing the installed files against the repo:

• The repo at commit 04bad33 has marketplace.json version 5.2.8 and does not contain the checking-gates / specifying-gates skills (those landed in 220f9d5, two commits later).
• The installed cache directory has version 5.5.0 in marketplace.json and contains both gate skills.
• diff -rq cache/.../5.5.0/ marketplaces/<marketplace>/ shows the installed cache is byte-identical with marketplace HEAD 26c74c8, modulo .git and .in_use.

So the actual installed code corresponds to 26c74c8, but gitCommitSha still reads 04bad33.

Impact

• Cosmetic / diagnostic: users (and agents helping users) inspecting installed_plugins.json get a misleading commit SHA.
• It complicates "which commit am I actually running?" debugging — I personally hit this and made a wrong inference before verifying via diff -rq.

Expected

After a successful plugin update, gitCommitSha should reflect the marketplace commit SHA that the plugin files were taken from (i.e., the marketplace branch HEAD at update time, or — for tarball-style installs — whatever upstream commit is being represented).

Environment

• Claude Code on Linux (WSL2)
• Plugin marketplace via GitHub source