Implement Modular MCP Server Configuration System

## Motivation

There's an emerging need for swappable MCP (Model Context Protocol) server configurations in our development environment. As we experiment with different implementations (e.g., kzms-mcp-server-git vs cyanheads/git-mcp-server), we need a system that allows us to:

1. Easily switch between different implementations of the same MCP server type
2. Maintain isolated dependencies using virtual environments
3. Preserve a consistent interface regardless of the underlying implementation
4. Follow the "spilled coffee principle" by making the setup reproducible

## Proposed Solution: Modular MCP Configuration System

We'll implement a modular system for managing MCP server implementations using a tracer bullet development approach - building incrementally toward our long-term vision while maintaining functionality at each step.

### Long-term Vision

A fully modular MCP configuration system where:
- Switching between implementations is a single command
- All dependencies are properly isolated in virtual environments
- Configuration is stored in dotfiles for reproducibility
- New implementations can be discovered and plugged in easily
- The entire process from build to deploy is streamlined

## Implementation Phases

### Phase 1: Foundation (Tracer Bullet)
- [x] Create private fork of kzms-mcp-server-git
- [ ] Create directory structure in dotfiles
- [ ] Implement basic wrapper script for Git MCP server
- [ ] Create implementation switching script
- [ ] Update MCP configuration to use wrapper

### Phase 2: Build & Deploy Pipeline
- [ ] Create setup script for MCP implementations
- [ ] Implement virtual environment management
- [ ] Add support for TypeScript-based implementations
- [ ] Standardize build process for different implementation types

### Phase 3: Discovery & Integration
- [ ] Create a registry of available implementations
- [ ] Implement automatic discovery of new implementations
- [ ] Add version tracking for implementations
- [ ] Create unified management interface

### Phase 4: Optimization & Expansion
- [ ] Extend system to other MCP server types
- [ ] Implement performance monitoring
- [ ] Add automatic updates
- [ ] Create comprehensive documentation

## Success Criteria

The ultimate proof of success will be how easily we can switch between different MCP server implementations. We should be able to:

1. Switch from kzms to cyanheads implementation with a single command
2. Revert back to previous implementations without configuration changes
3. Add new implementations with minimal effort
4. Maintain consistent behavior across different implementations

## Next Steps

1. Create the directory structure in dotfiles
2. Implement the basic wrapper script for Git MCP server
3. Test with our private fork of kzms-mcp-server-git

We'll follow a tracer bullet development approach, focusing on getting a minimal end-to-end solution working first, then iteratively improving it.

The issue names only a dotfiles directory structure, a Git MCP wrapper script, an implementation-switching script, and MCP configuration; it names no existing files or tests. Start by scoping Phase 1 around those entry points and define done as switching between the two named Git implementations with one command while preserving the MCP interface and reproducible setup.

Written by the indexing model from the issue text.