feat: Create unified mono MCP server for simplified tool management

# Mono MCP Server Architecture

## Problem Statement

Currently using multiple MCP servers from different sources creates security and management complexity:
- Need to selectively untrust dangerous tools with complex `/tools untrust` commands
- Multiple configuration files and integration points
- Difficult to audit and understand all available tools
- Security policies scattered across different servers

## Proposed Solution

Create a single, unified MCP server that consolidates all needed functionality:

### Benefits
- **Security**: Curated tool set with built-in security policies
- **Simplicity**: Single `/tools trustall` without fear
- **Control**: Complete ownership of tool implementations
- **Integration**: Tools can share context and state
- **Maintenance**: Single codebase to review and update

### Architecture Options

#### Option 1: Wrapper/Proxy Pattern
```
Mono MCP Server
├── GitHub Module (wraps existing github MCP)
├── Filesystem Module (wraps existing filesystem MCP)
├── AWS Module (wraps built-in use_aws)
├── Custom Tools Module (qsafe, etc.)
└── Security Layer (built-in policies)
```

#### Option 2: Native Implementation
```
Mono MCP Server
├── Core Framework
├── Tool Modules (native implementations)
├── Configuration System
└── Security/Policy Engine
```

### Implementation Plan

#### Phase 1: Proof of Concept
- [ ] Create basic MCP server framework
- [ ] Implement core tools: qsafe, basic GitHub operations, filesystem operations
- [ ] Test Amazon Q integration
- [ ] Validate security model

#### Phase 2: Migration
- [ ] Gradually migrate tools from external MCP servers
- [ ] Add environment-specific configurations (work vs personal)
- [ ] Implement cross-tool integrations
- [ ] Maintain backward compatibility

#### Phase 3: Enhancement
- [ ] Advanced security features and policies
- [ ] Custom workflows and automation
- [ ] Performance optimizations
- [ ] Documentation and examples

### Technical Considerations

- **Language**: Python/Node.js for rapid development, Go/Rust for performance
- **Configuration**: Environment-specific tool sets using existing mcp-environment.sh patterns
- **Security**: Built-in policies rather than external untrust commands
- **Updates**: Strategy for incorporating upstream changes

### Success Criteria

- [ ] Single MCP server replaces all current external servers
- [ ] `/tools trustall` works safely without selective untrusting
- [ ] All current workflows continue to function
- [ ] Improved security posture and auditability
- [ ] Simplified configuration and maintenance

This aligns with the dotfiles philosophy of complete control over the development environment with reproducible, version-controlled tooling.

Start by reviewing the existing mcp-environment.sh patterns and the repository's current MCP configuration and integration points. Decide whether the wrapper/proxy or native implementation fits, then define the Phase 1 proof of concept and validate it against Amazon Q, the security model, and the listed success criteria.

Written by the indexing model from the issue text.