Evaluate and test monarchmoney-enhanced fork (rules engine, caching, session mgmt)

[jamiew]

we currently depend on monarchmoneycommunity (bradleyseanf), pinned to a commit SHA. while analyzing the fork landscape (see "Upstream Library & Fork Landscape" in CLAUDE.md, added in #9) the sibling fork keithah/monarchmoney-enhanced stood out — MIT, on PyPI as monarchmoney-enhanced, ~6,100 LOC vs our fork's ~3,500.

it adds whole capability areas neither our fork nor the parent has, several mapping directly onto existing CLAUDE.md TODOs:

• transaction rules engine — categorization/amount/ignore rules, preview, apply-to-existing (→ auto-categorization TODO)
• built-in caching layer — preload_cache, clear_cache, cache metrics (→ caching/performance TODO)
• proactive session management — validate_session, ensure_valid_session, is_session_stale (→ advanced session mgmt TODO)
• goals — get/create/update/delete (→ goal tracking TODO)
• bills — get_bills
• merchants — get_merchants, get_edit_merchant
• insights — get_insights, get_net_worth_history, get_investment_performance, get_credit_score

caveat: it's not a strict superset. our current fork has a few methods it lacks (upload_attachment, reset_budget, flex-budget methods, get_credit_history). so this is a real decision, not a drop-in.

two paths to evaluate:

• switch the dependency to monarchmoney-enhanced and accept losing a few methods (or re-add them)
• stay on our fork and cherry-pick the specific GraphQL queries we want (rules + caching + session validation are the highest-leverage)

needs hands-on testing against a live account before committing either way.

to explore:

• diff the two libs' method surfaces and confirm exactly what we'd gain/lose
• spike the caching + session-validation pieces since they improve reliability for every tool
• decide switch-vs-cherry-pick