Plugins: allow agents to declare scoped tool permissions for background execution

Problem

Plugin agents can declare which tools they use via tools: ["Read", "Edit", ...] in their agent definition, but this only controls tool availability — it doesn't affect the user's permission mode. When an agent runs in the background (run_in_background: true), any tool that requires interactive approval silently fails because there's no prompt surface.

This makes background agents unable to perform any write operations unless the user globally allows Edit/Write in their permission settings, which is too broad a security posture.

Use Case

A plugin has a background agent that:

1. Reads source files across the codebase
2. Generates derived artifacts (e.g., summaries, indexes, documentation)
3. Writes results to a specific plugin-owned file via the Edit tool

The agent is designed to run in the background (~60-90s) to avoid blocking the main conversation. But it can't complete its work because Edit requires interactive approval and background agents can't prompt for it.

This pattern applies broadly — any plugin that wants to do background processing and write results to plugin-managed files hits this wall.

Request

Allow plugins to declare scoped permissions for their agents — for example, Edit access limited to specific file patterns (e.g., .plugin-dir/**). The user's approval of the plugin installation would serve as the trust boundary, while the scoping limits the blast radius.