bug(vibe): unmapped canonical permission categories emit [tools.<category>] entries Vibe has no tool for, so a deny is silently inert

[dyoshikawa]

Background

Spun out of #2423 (recorded there by the maintainer as worth its own issue).

toVibeToolName in src/features/permissions/vibe-permissions.ts falls back to the canonical category name verbatim when CANONICAL_TO_VIBE_TOOL_NAMES has no entry (CANONICAL_TO_VIBE_TOOL_NAMES[category] ?? category). Canonical categories with no Vibe counterpart — e.g. glob and notebookedit — therefore emit [tools.glob] / [tools.notebookedit] tables into vibe.toml for tools Vibe does not have. A deny authored on those categories looks applied but is silently inert, which is the dangerous direction.

Unlike the agent → task case fixed in #2441 there is no correct name to rename to.

Solution

Adopt the "skip with a warning" behaviour the grokcli permissions adapter already has: when a canonical category has no Vibe tool mapping, do not emit a [tools.<category>] table; log a warning naming the category and the affected rules. Keep import lenient (an unknown on-disk [tools.*] table should still round-trip untouched as tool-specific content). Add unit coverage for the deny-inert case in both directions.