[Feature] Improve MCP architecture for multi-repo and multi-session support

Describe the Issue

repowise's MCP server architecture is fundamentally single-tenant - one MCP server process per repository - which creates several limitations for multi-repo and multi-user workflows.

Steps to Reproduce

1. Open multiple IDEs/CLIs accessing different repositories
2. Each requires its own MCP server process: repowise mcp /path/to/repo1
3. For SSE transport, each needs unique port: repowise mcp --transport sse --port 7338
4. Try concurrent generation operations on the same repository
5. Observe SQLite database locking and port conflicts

Current Limitations

No Centralized MCP Server

• Each repository requires its own MCP server process
• Server uses module-level globals tied to one repository path
• MCP config generation creates repository-specific configurations

SQLite Database Locking

• Multiple MCP servers accessing the same SQLite database experience locking during write operations
• SQLite allows multiple readers but only one writer at a time
• Generation operations involve both reads and writes, causing blocking for concurrent processes

SSE Transport Port Management

• SSE transport requires unique ports per repository (default: 7338)
• Creates configuration overhead for multi-repo workflows
• Each client needs repository-specific port settings

No Multi-CLI Session Support

• Architecture prioritizes single-user workflows over multi-session coordination
• No centralized session broker or lock management for generation operations
• Resource contention on vector stores and search indices

Expected Behavior

• Single MCP server should be able to serve multiple repositories
• Multiple CLI/IDE instances should access the same repository without conflicts
• SSE transport should not require manual port management per repository
• Generation operations should handle concurrent access gracefully

Proposed Solution

1. Centralized session broker to coordinate multiple MCP connections
2. Shared vector store with concurrent access patterns
3. Lock management for generation operations

Current Workarounds

1. Use stdio transport for IDE integration (avoids port conflicts)
2. Hosted version for team environments with cross-repo intelligence
3. Port allocation strategy for SSE transport (reserve port ranges)

Environment

• OS: Windows 10
• Python version: 3.14
• Repowise version: 0.3.0
• Installation method: pip

Additional Context

The current design prioritizes simplicity and single-user workflows. For team environments requiring multi-repo intelligence, architectural improvements are needed to support:

• Multiple developers working on the same repository simultaneously
• Single MCP server serving multiple repositories
• Web-based clients without port management overhead
• Concurrent generation operations without database locking

This would make repowise more suitable for team environments and complex multi-repo workflows.
Achieve the same results as oraios/serena mcp.

• Deepwiki

Start with the repowise mcp entry point and compare the stdio and SSE transport paths described in the issue. Map how repository paths, SQLite access, generation operations, and ports are scoped today; done means one server can serve multiple repositories and sessions without port conflicts or concurrent-generation database locking.