fix: lock the store's summary cache and cache the MCP graph build (#130)

[CryptoJones]

Closes #130.

• Web 500s: the web UI runs sync endpoints on FastAPI's threadpool over a single shared OmiStore, so concurrent list_notes() calls mutated the summary cache while another thread iterated it → RuntimeError: dictionary changed size during iteration under the 5-second poll. The cache is now guarded by a lock.
• Repeated full-vault parse: the MCP server's five graph tools each rebuilt the whole [[wikilink]] graph per call. The build is now cached, invalidated by a cheap vault signature (note count, total size, newest mtime), so a burst of graph queries costs one parse and any write busts it.

Scope note: the single-client stdio MCP server's sync handlers are deliberately left on the event loop. Blocking there delays only that one client's pings/cancellations (not a crash), and the graph cache removes the pathological repeated-parse cost that was the real harm — an async refactor of the critical server every session depends on is disproportionate risk for the remaining latency.

Test plan

• New tests: list_notes() hammered from 8 threads raises no dict-resize error; the graph build is cached across 3 graph tools (1 build) and busted by a write (2 builds).
• Full suite: 722 passed, 1 skipped. ruff + mypy clean.

🤖 Generated with Claude Code

Proudly Made in Nebraska. Go Big Red! 🌽 https://xkcd.com/2347/