Notify users when a plugin update is available (lazy, daily-throttled)

Problem

claude plugin list shows the installed version but not whether a newer version exists in the marketplace. Users only discover updates by running claude plugin marketplace update and claude plugin update <name> manually, which means installs silently drift behind.

Proposed behavior

When a wingspan skill or slash command is invoked, perform a lazy, throttled version check:

1. On PreToolUse for wingspan-scoped invocations, read a cache file (e.g. ~/.claude/plugin-state/vgv-wingspan/last-check).
2. If the cached timestamp is older than 24h, fetch the current version from the marketplace manifest and compare against the installed version.
3. If a newer version exists, print a single non-blocking line like:

   vgv-wingspan 0.0.2 is available (you have 0.0.1). Run \claude plugin update vgv-wingspan` to upgrade.`

4. Update the cache timestamp regardless of outcome.

Why this shape

• Lazy (not SessionStart): zero cost for users who don't use wingspan that day; avoids slowing session startup.
• Daily throttle: one reminder per day per plugin, not per invocation — avoids spam.
• In-context: the notice arrives while the user is already engaging with wingspan, so it's relevant rather than random.
• Single line, non-blocking: doesn't interrupt the workflow.

Notes

• Skills are markdown-as-instructions, so the check has to live in a real hook (executable), not inside skill markdown.
• If multiple VGV plugins adopt this pattern, a shared helper in a future "wingspan core" would keep the implementation DRY and let users silence all VGV update nudges with a single setting.

Alternative considered

A SessionStart hook was considered but rejected — it would run for every session whether or not the user touches wingspan that day, and if every plugin did the same, startup would get noisy fast.

Start by locating the executable hook handling PreToolUse for wingspan-scoped skills or slash commands, then trace how the plugin marketplace manifest and installed version are accessed. Implement the 24-hour cache check and non-blocking notice described in the issue, and verify that the timestamp is updated for both successful and failed checks without running on unrelated invocations.