Simplify tool configuration to boolean `unattended` with runtime interaction choices

The current tool calling configuration system requires users to pre-configure whether tools run in always, ask, or edit mode. This creates inflexibility when users can't predict beforehand whether they'll want to review, edit, or run a tool directly during an interactive session.

Context

Currently, tool configuration uses a RunMode enum with three values:

• Always: Run without confirmation (should probably be renamed to "unattended")
• Ask: Prompt for confirmation before running
• Edit: Open editor to modify tool call arguments before running

Users must decide the interaction mode at configuration time, but in practice, the choice between asking for confirmation vs. editing often depends on the specific context of the tool call, which isn't known until runtime.

According to the current implementation in crates/jp_config/src/mcp/server/tool.rs, tools default to RunMode::Ask, and the interaction flow in crates/jp_cli/src/cmd/query/event.rs shows that when in Edit mode, if users empty the arguments, the system falls back to Ask mode anyway.

Alternatives

Users could work around this limitation by:

1. Setting all tools to Edit mode and simply saving without changes when they don't want to edit
2. Dynamically reconfiguring tools before each session
3. Using different configuration profiles for different scenarios

However, these alternatives add unnecessary complexity and cognitive overhead.

Proposed Implementation

Replace the current three-state RunMode enum with:

1. A simple boolean unattended field in tool configuration
2. For attended tools (unattended = false), show a four-choice runtime prompt:
   • run - Execute the tool call as-is
   • reject - Skip the tool call entirely
   • reject with message - Skip with custom rejection message
   • edit - Open editor to modify arguments before running

This approach separates the configuration concern (attended vs. unattended) from the runtime interaction choice (run/reject/edit), providing better user experience and more appropriate defaults.

Tasks

• Update RunMode enum in crates/jp_config/src/mcp/server/tool.rs to a boolean unattended field
• Modify the tool calling interaction logic in crates/jp_cli/src/cmd/query/event.rs to show four-choice prompt for attended tools
• Add "reject with message" functionality that returns a custom user-provided message instead of tool results
• Update configuration parsing and validation to handle the new boolean field
• Update documentation to reflect the new configuration approach
• Consider backward compatibility or migration path for existing configurations

Resources

• https://github.com/dcdpr/jp/blob/e100ef9cb42ecf00a6a3d76b6023d57795b153fe/crates/jp_config/src/mcp/server/tool.rs#L168-L189
• https://github.com/dcdpr/jp/blob/ceeb64f91af64fcccb98956022e543a001ec8d56/crates/jp_cli/src/cmd/query/event.rs#L254-L264

Start by reading the RunMode definition in crates/jp_config/src/mcp/server/tool.rs and the interaction flow in crates/jp_cli/src/cmd/query/event.rs. Trace configuration parsing and validation from those entry points, then identify the existing tests or checks for tool calls. Done means attended tools offer run, reject, reject with message, and edit choices, while configuration and documentation reflect the boolean field and any migration path.