Project-scoped plugins fail in git worktrees: Plugin "<name>" not cached at (not recorded)

Description

A plugin installed at project scope is recorded in ~/.claude/plugins/installed_plugins.json with the absolute projectPath of the checkout it was installed from. When the same repository is used via git worktree at a different path, the checked-in .claude/settings.json (with enabledPlugins) travels into the worktree, but no install record matches the worktree's path. Startup then reports:

1 error:
    Plugin "example-plugin" not cached at (not recorded)

The plugin's files are present in ~/.claude/plugins/cache/ — only the path-keyed registration fails, so the plugin does not load in any worktree.

Reproduction

1. In a repo, check in .claude/settings.json with extraKnownMarketplaces and enabledPlugins for a marketplace plugin (the team marketplaces flow):

``json
{
"enabledPlugins": { "example-plugin@example-marketplace": true },
"extraKnownMarketplaces": {
"example-marketplace": {
"source": { "source": "github", "repo": "example-org/claude-plugins" }
}
}
}
``

1. On a machine with no prior install of the plugin, open Claude Code in the repo (e.g. ~/work/my-repo), trust the folder, and accept the prompted install → a scope: "project" record is created pinned to that absolute path.
2. git worktree add ../my-repo-feature some-branch (a sibling path, outside the main checkout).
3. Start Claude Code in ~/work/my-repo-feature → error above; the plugin does not load.

Expected

A worktree is the same repository — git rev-parse --git-common-dir from the worktree resolves to the main checkout's .git. Project-scoped plugin install records should be resolved through the git common directory (or the main worktree's toplevel), so all worktrees of a repo share its install records.

Alternatively (or additionally): when a plugin is enabled here but only installed for a different project path, re-offer installation instead of erroring — currently this state neither resolves nor triggers the team-marketplace install prompt.

Notes

• v2.1.144 fixed the adjacent fresh-machine variant ("Fixed plugins enabled in your own settings showing 'not cached' errors after first load on a fresh machine"). This case differs: a record exists, but for a different absolute path.
• Worktrees created under the main checkout (e.g. .claude/worktrees/… via the built-in worktree feature) resolve fine, since project-root discovery walks up into the main repo. The failure is specific to the common git worktree add ../sibling layout.
• Verified the scope semantics directly: with a user-scoped install record the same plugin loads from any directory, including sibling worktrees; with only a project-scoped record, claude plugin list from an unrelated directory shows the plugin disabled, and from a sibling worktree the startup error above is produced.
• Workaround: claude plugin uninstall + reinstall with --scope user, which has no projectPath and resolves everywhere.

Environment

• Claude Code 2.1.170 (also observed on earlier 2.1.x)
• macOS
• Plugin distributed via a GitHub-hosted team marketplace