[Feature Request] Allow muting notifications per extension rule ("Don't show again")

[Cyclodex]

Problem

Warnings currently re-fire on every window open, forever. There is no way for a developer to acknowledge a warning they have consciously decided to live with — for example, keeping an unwantedRecommendations extension enabled on purpose in one project. The only way to silence it today is to edit the shared config file, which changes the rule for the whole team.

This also blocks the recommendations support discussed in #12: without a mute, warning on every rule violation would be too noisy to ship.

Proposal

Add a "Don't show again" action to the warning notifications, plus a command to reset mutes.

Storage

context.workspaceState, not globalState — muting is a per-project decision ("in this repo I accept Vetur"). src/update.ts already uses globalState for the version check, so the pattern exists.

Key on the rule, not just the extension id

A mute should be keyed on the combination of:

• extension id
• the configured version range (if any)
• the version of the extension installed at the time of muting

Keying on the id alone would mean that a maintainer later tightening @^1.0.0 to @^2.0.0 stays silently muted — a stale mute hiding a real problem. Keying on the full triple means any change to the rule or to the installed version invalidates the mute and warns once more. This is self-healing and fails toward informing the user rather than hiding things from them.

Notification actions

• Show (existing behaviour)
• Don't show again (persistent mute, as described above)
• optionally Remind me later (session-only)

Reset command

A Reset notification mutes command is required, not optional. A workspaceState mute is otherwise invisible and unreachable, so a mis-click would be permanent.

Summary dialog

The end-of-run summary modal (src/extension.ts, the isConfirm call) must count only non-muted items, otherwise muted extensions still get nagged about in aggregate.

Scope

Applies to both unwantedRecommendations (existing) and the recommendations support proposed in #12. Useful on its own, independent of #12.