Summary

The tool catalog types carry a plugin discriminator (source: "core" | "plugin", pluginId?: string) with no UI consumer. No plugin badge, filter, or detail view renders based on these fields — the plugin system has been gutted per CLAUDE.md "What's being removed".

Evidence

• ui/src/ui/types.ts:356-357 — ToolCatalogEntry:

  source: "core" | "plugin";
  pluginId?: string;

• ui/src/ui/types.ts:365-366 — same on ToolCatalogGroup
• grep -rn 'pluginId\|source: "plugin"' ui/src/ — zero consumers

Why this is safe

The discriminator narrowing from "core" | "plugin" to "core" is a valid type-level change because no runtime path ever assigns "plugin" and no reader branches on the value. If backend still emits "plugin" from a legacy tool catalog, narrowing the UI type would surface a type error at deserialization — that's the correct signal to coordinate.

Changes

• ui/src/ui/types.ts:356-357 — narrow source to "core" (or drop field entirely if no code branches on it); delete pluginId?: string
• ui/src/ui/types.ts:365-366 — same on ToolCatalogGroup
• Verify: grep catalog deserialization paths; confirm backend doesn't emit "plugin" values

AC

• grep -rn 'pluginId' ui/src/ returns zero hits
• grep -rn 'source: "plugin"\|source:"plugin"' ui/src/ returns zero hits
• pnpm check green
• pnpm test green
• pnpm test:ui:smoke green

Context

Follow-up to the plugin-system gutting (CLAUDE.md § Fork Context "What's being removed"). Discovered during the post-#2336 UI remnants audit.