feat(mcp, plugin): Let command plugins serve tools

[JeanMertz]

A tool can name a command plugin as its source, as in source = "plugin.command.ticket.create", and JP runs the plugin for each call under the query's own configuration. The plugin receives its effective plugins.command.<name>.options, including nested .jp.toml files, conversation config, and --cfg overrides, rather than starting a child jp that resolves configuration from the workspace root. A package in a monorepo that points the ticket plugin at its own directory gets its tickets written there.

Plugin tools follow the same rules as local tools. run, result, and format apply unchanged, and access grants, including conversation.tools.'*'.access and --mount, are compiled and sent to the plugin to enforce. The binary is admitted once when the turn starts, under the same plugins.command.<name>.run policy and saved approvals as jp <plugin>. A refused plugin's tools are left out of the turn with a notice, forcing one with --tool fails the query, and a binary replaced mid-turn is refused.

style.parameters = "tool" lets a local or plugin tool describe its own call: JP runs the tool with the format_arguments action instead of a separate formatter command. Tool calls need plugin protocol 12, in which init carries a tool, stdin closes after it, and the plugin answers with tool_outcome followed by exit. The ticket tools still run through just serve-tools; moving them onto plugin.command.ticket is left to the branch that adds their plugin handler.

Also files T-0vnd5xf, a cancelled tool whose processes outlive it (now covered on Unix by jp_process, still open on Windows), and T-0vnx563, finding open PRs that touch a path.

Closes: T-0vm44ks