docs(architecture): explain RAG design decisions

[fanza-ks]

Summary

• Adds a Design decisions section to docs/architecture.md explaining why the RAG pipeline is shaped the way it is, prompted by an external question asking how the architecture was arrived at (and why it differs from generic notes-RAGs like gbrain).
• Covers: per-declaration chunking, Herald-style informalization before embedding, dependency-aware topological ordering, HyDE on the query side, dual Postgres + Chroma store, and model/task-type tiering.
• Ends with a small comparison table contrasting this pipeline against a generic notes-RAG.

Test plan

• Render docs/architecture.md (VS Code preview or on GitHub) and verify heading hierarchy, code-block formatting, and the comparison table.
• Confirm relative links (../database/vector_db.py, etc.) resolve on the GitHub view.
• Cross-check the cited claims against the code:
  • database/vector_db.py:43 — hybrid embedding-input string
  • database/informalize.py — ±2 neighbours + dependency context
  • database/embedding.py — RETRIEVAL_DOCUMENT vs RETRIEVAL_QUERY

🤖 Generated with Claude Code

[fanza-ks]

Following up on a question by Shlok Vaibhav on Zulip, I've added a more detailed explanation of what we do and why we made certain design choices for the RAG system in physlibsearch