Plugin hook fails after cache hash changes: stale CLAUDE_PLUGIN_ROOT path

Bug Description

Plugin hooks reference ${CLAUDE_PLUGIN_ROOT} which resolves to a content-hash directory under ~/.claude/plugins/cache/<source>/<plugin>/<hash>/. When the plugin is updated (producing a new hash), old sessions' hooks still reference the previous hash directory, which no longer exists.

This results in persistent errors on every stop event:

Stop hook error: Failed with non-blocking status code: /bin/sh: 
/Users/user/.claude-work/plugins/cache/claude-plugins-official/ralph-loop/d5c15b861cd2/hooks/stop-hook.sh: 
No such file or directory

The directory d5c15b861cd2 was cleaned up when the plugin updated, but the session's hook configuration still points to it.

Steps to Reproduce

1. Install a plugin with hooks (e.g., ralph-loop from claude-plugins-official)
2. Start a Claude Code session — hooks work fine
3. The plugin gets updated (new content hash is created, e.g., b10b583de281)
4. Old cache directory (e.g., d5c15b861cd2) is cleaned up
5. The running session's stop hook now fails on every invocation because CLAUDE_PLUGIN_ROOT still resolves to the deleted hash directory

Expected Behavior

Either:

• The session should detect that the plugin cache has changed and update CLAUDE_PLUGIN_ROOT to the new hash directory
• Or old cache directories should not be cleaned up while active sessions reference them
• Or the hook runner should resolve CLAUDE_PLUGIN_ROOT at execution time (not at session init time)

Actual Behavior

The hook path is baked in at session init and becomes stale when the cache directory is cleaned up. The error persists for the lifetime of the session. Restarting Claude Code resolves it until the next plugin update.

Environment

• macOS (Darwin 25.2.0)
• Claude Code (work profile using ~/.claude-work/)
• Plugin: ralph-loop@claude-plugins-official
• Multiple hash directories exist in cache, but session references a deleted one

Additional Context

This is particularly confusing because AI agents in previous sessions have been asked to "fix" this error and have applied incorrect fixes (e.g., chmod +x on existing hook files) because the actual problem — a missing directory — is not obvious from the error message. The error says "No such file or directory" which could mean either the file lacks permissions or doesn't exist.