Document domain model and interface parity in architecture docs

[jafreck]

Problem

docs/architecture.md documents the pipeline stages and MCP tools but does not articulate:

• The domain taxonomy (code structure, git, docs, coverage/testing, metrics, agent memory)
• The write-side vs read-side separation
• Which capabilities are available through which interface (MCP, CLI, programmatic API)
• The rationale for keeping all domains in a single package (shared SQLite DB as integration point)

This makes it hard for contributors and users to understand why the feature set is cohesive and where to add new capabilities.

Proposal

Add a "Domain Model & Interface Parity" section to docs/architecture.md covering:

1. Domain taxonomy table — each feature domain, its write-side stage(s), its read-side tool(s), and its DB tables
2. Interface matrix — MCP / CLI / API coverage per domain (identifying gaps being addressed by companion issues)
3. Design rationale — why all domains live in one package (single DB artifact, single MCP server, composable pipeline stages already provide internal modularity)

Acceptance criteria

• Domain taxonomy table in architecture docs
• Interface parity matrix in architecture docs
• Brief design rationale section explaining the single-package decision