installed_plugins.json gitCommitSha is never refreshed on /plugin update

Summary

installed_plugins.json records a gitCommitSha field on initial /plugin install. Subsequent /plugin update operations correctly update installPath, version, and lastUpdated, but gitCommitSha stays pinned to the original install commit forever.

Environment

• Claude Code version: 2.1.136
• Platform: macOS 24.6.0
• Plugin: cleos-connector@cleos-labs (github-sourced marketplace)

Reliable reproduction

1. /plugin install <plugin>@<marketplace> — gitCommitSha records the source repo's HEAD at install time, e.g., abc123…
2. Publish a new version of the plugin (new commit def456… on the source repo's main)
3. /plugin update <plugin>@<marketplace> — completes successfully, version field bumps, lastUpdated bumps
4. Inspect ~/.claude/plugins/installed_plugins.json — gitCommitSha is still abc123…, not def456…

Concrete instance from today

Across PRs #8, #9, #10, #11, #12, #13 in Austentel/cleos-plugin, the connector advanced from 2.0.1 (commit 2acc6cf) to 2.0.5 (commit f76a0bb post-merge). After multiple /plugin update cycles:

{
  "cleos-connector@cleos-labs": [{
    "installPath": ".../2.0.5",
    "version": "2.0.5",
    "lastUpdated": "2026-05-09T16:..." ,
    "gitCommitSha": "2acc6cf0513a1fc49bfa8e3272580fa0b3144b55"   ← still 2.0.1's SHA
  }]
}

Expected

gitCommitSha reflects the source repo's commit corresponding to the currently installed version.

Actual

Field is stale forever after the first install.

Impact

• Cosmetic but breaks "which-version-am-I-on" debugging and audit
• If a marketplace publishes a non-monotonic version (e.g., a hotfix to a previous version's tag), the SHA can disagree with the installed code without any way to tell from the install record alone
• Affects scripts that rely on this field for plugin provenance

Suggested fix

Update gitCommitSha whenever lastUpdated is bumped, sourcing the SHA from the marketplace's git ref or release metadata that the update operation already fetched.