plugins/blocklist.json contains stale test entries (code-review, fizz) that block the official code-review plugin despite its own disable-model-invocation: false

Summary

The locally-synced ~/.claude/plugins/blocklist.json (fetched centrally, per its fetchedAt field) contains what appear to be leftover test entries that block the official code-review@claude-plugins-official plugin from being invoked programmatically by the model:

{
  "plugin": "code-review@claude-plugins-official",
  "added_at": "2026-02-11T03:16:31.424Z",
  "reason": "just-a-test",
  "text": "This is a test #5"
}

A second entry (fizz@testmkt-marketplace, reason "security") is also present and looks similarly like test data.

Evidence this is unintentional

• The plugin's own command definition (plugins/code-review/commands/code-review.md) explicitly declares disable-model-invocation: false in its frontmatter, i.e. the plugin author intended it to be invocable by the model.
• The blocklist entry's reason ("just-a-test") and text ("This is a test #5") read as debug/QA artifacts from testing the blocklist distribution mechanism itself, not a deliberate decision to disable this legitimate, official, first-party plugin.
• Issue #76499 independently discovered the same two blocklist entries while investigating an unrelated problem (missing custom sub-agents) and dismissed them as "unrelated test entries" -- confirming this blocklist content is broadly distributed to users, not local to one machine.

Impact

• Attempting to invoke code-review programmatically (e.g. via the Skill/tool-calling mechanism from within another skill's automated workflow) fails with an invocation-blocked error, even though the plugin itself declares it should be model-invocable.
• This silently breaks any automated workflow that expects to chain into /code-review (e.g. a project-level skill's "run code review after implementation" step), forcing a fallback to manual/ad-hoc review instead.
• Manual, user-typed invocation of /code-review appears unaffected (consistent with the blocklist targeting model/tool-initiated invocation specifically), which is why this may have gone unnoticed for anyone not chaining it from another automated skill.

Suggested fix

• Remove the code-review and fizz test entries from the distributed blocklist.json, or
• Add a staging/production distinction to the blocklist distribution pipeline so test entries used to validate the blocklist mechanism can't leak into the production feed served to real users.

Environment

• Windows 11
• Blocklist fetchedAt: 2026-03-27T06:30:42.262Z
• Related: #76499