Unified config file (file < env/.env < CLI precedence) consolidating RAG_* + attachment + MCP settings

[fmasi]

Motivation

Config today is split: env vars / .env (src/config/settings.py RAGConfig + the LLM client) and the per-corpus profile JSON (CorpusProfile). There's no general config-file base layer. As settings accumulate (attachment extractor + cloud opt-in from #38, and especially the MCP server settings in Phase 1b #32 — port, exposed tools), a single canonical config file becomes worthwhile.

Proposal

Add a config-file base layer with standard precedence (low → high):

1. config file — e.g. ~/.mailrag/config.toml (tomllib is stdlib, read-only; or YAML, already a dep)
2. env / .env — existing RAG_* vars override the file
3. CLI flag — highest priority per-invocation override

Consolidate the existing RAG_* settings (LLM provider/model/temperature/base-url/key, embedding provider/model/batch/workers, chunk size/overlap) plus the new RAG_ATTACH_EXTRACTOR (#38) and the future MCP settings.

Scope / sequencing

• Target: land alongside or just before MCP (Handle email attachments — Phase 1: preserve + on-demand LLM load; Phase 2: embed content #32) — that's when the settings pile up and the loader pays for itself.
• Migrating existing RAG_* through the loader touches settings.py, which has fragile test_settings_embedding_provider cases — do it carefully with tests for the precedence cascade.
• Until then, attachments: refactor extraction into a clean handler+OCR-provider subsystem, with local vision-LLM (gemma-4) as the default OCR backend #38 uses code-default llm < env RAG_ATTACH_EXTRACTOR < CLI --extractor (forward-compatible: the same keys move into the file later).

Refs: #38 (extractor + cloud opt-in), #32 (MCP settings), src/config/settings.py.