feat: Implement tool permission system (local/project/global)

## Feature Request
Create a flexible tool permission system that allows configuring permissions at different scopes: local (project), project-type, and global levels.

## Problem
Currently, tool permissions are configured per-session or globally, but there's no granular control based on context:
- Some projects need write access, others should be read-only
- Work vs personal projects have different security requirements
- Can't enable autonomous operation without appropriate permission boundaries

## Desired System
```
Permission hierarchy (most specific wins):
1. Local (.claude/settings.local.json) - project-specific
2. Project-type (work vs personal) - category-level
3. Global (~/.claude/settings.json) - fallback defaults
```

## Use Cases
- **Work projects**: More restrictive, no AWS access, limited write
- **Personal projects**: Full access to all tools
- **Documentation repos**: Read-only access
- **Active development**: Full write/execute permissions

## Implementation Ideas
1. Extend current allowedTools/deniedTools pattern
2. Support permission inheritance and overrides
3. Environment-based detection (WORK_MACHINE variable)
4. Clear permission resolution logging

## Success Criteria
- Can set different permissions per project
- Permissions persist and are version controlled
- Clear precedence rules
- Enables safe autonomous operation
- Easy to audit current permissions

Related: #592 (parent task)

Start by reviewing the current allowedTools/deniedTools configuration and the related parent task #592. Then inspect the proposed .claude/settings.local.json and ~/.claude/settings.json scopes, along with WORK_MACHINE detection; done means documented precedence, inheritance and overrides, persistent project permissions, resolution logging, and auditable autonomous-operation boundaries.

Written by the indexing model from the issue text.