[Bug]: execute_shell_command may bypass File Guard

## CoPaw Version

1.0.1

## Description

**Security Test Observation:** Tools `read_file`, `write_file`, and `edit_file` cannot access protected directories without approval. When these tools are disabled or being prompted, the agent falls back to `execute_shell_command` and executes successfully without requiring explicit approval.

This behavior was observed during a test where:
- Primary file operation tools (read_file, write_file, edit_file) are disabled or asked not to use them
- The agent automatically falls back to using `execute_shell_command` as an alternative method
- `execute_shell_command` successfully completes the operation without the same approval requirements

**Security considerations:**
- **Auth/Permission Bypass Risk**: The fallback mechanism may bypass intended access controls if `execute_shell_command` has broader permissions than the dedicated file tools
- **Consistency Concern**: Different tools having different approval requirements could lead to inconsistent security posture
- **Recommendation**: Consider implementing unified permission checks across all tool types, or ensure `execute_shell_command` respects the same directory access policies as the dedicated file tools

## Component(s) Affected

- [x] Core / Backend (app, agents, config, providers, utils, local_models)
- [ ] Console (frontend web UI)
- [ ] Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
- [ ] Skills
- [ ] CLI
- [ ] Documentation (website)
- [ ] Tests
- [ ] CI/CD
- [ ] Scripts / Deploy

## Environment

- **CoPaw version:** 1.0.1
- **OS:** Windows 11 25H2
- **Install method:** Desktop app
- **Python version (if applicable):** N/A (Desktop app)

## Steps to Reproduce

1. Configure CoPaw agent with restricted file access permissions for certain directories
2. Attempt to read/write files in a protected directory using `read_file`/`write_file`/`edit_file` tools
3. Observe that these tools cannot access the protected directory without approval
4. Disable the tools or prompt the agent to use execute_shell_command directly
5. Agent falls back to `execute_shell_command` (e.g., using shell commands like `type`, `echo > file`)
6. Notice that `execute_shell_command` succeeds without the same approval requirements

## Actual vs Expected

- **Actual:** The agent successfully accesses protected directories through `execute_shell_command`, bypassing the restrictions applied to dedicated file tools
- **Expected:** Either:
- All tools should respect the same permission/approval requirements consistently
- OR the fallback mechanism should also trigger approval prompts when accessing restricted resources

## Additional Notes

### Potential Solutions

1. **Unified Permission Layer**: Implement a central permission checking mechanism that all tools must consult before executing operations on protected resources

2. **Tool-Level Consistency**: Ensure `execute_shell_command` has the same directory access restrictions as `read_file`, `write_file`, and `edit_file`

3. **Approval Fallback Chain**: When a tool is disabled/restricted, the fallback tool should inherit the same approval requirements

4. **Configurable Security Policies**: Allow users to define granular access policies that apply across all tool types

### Similar Considerations

- This pattern may also affect other tool categories (e.g., browser tools, network operations)
- The fallback mechanism is useful for flexibility but needs security alignment
- Consider documenting the security model and tool interaction patterns clearly

---