feat: multi-page navigation with st.navigation and Material icons

[jschloman]

Closes #28

Summary

• visualize.py is now a ~40-line entrypoint; all chart and data logic extracted into focused modules
• components/sidebar.py — shared data loading, caching, and global date filter; stores result in st.session_state['df'] so navigation doesn't reload data from disk
• pages/overview.py — metrics + top charts
• pages/music.py — listening timeline + cumulative growth
• pages/places.py — 3D geographic map (fly-through, export)
• pages/insights.py — patterns, narrative, granular filters
• pages/fitness.py, pages/culture.py, pages/beer.py — friendly empty states ready for future source plugins
• Navigation uses st.navigation + st.Page with Material icons; pages grouped into Overview / Music / Places / Health / Culture nav sections

Source plugin contract (must hold before merge)

All source plugins — including those wired through components/sidebar.py and DataBroker — must satisfy two architectural principles:

1. Download-then-display

No plugin may make outbound network or API calls at Streamlit runtime. SourcePlugin.fetch() reads only from a previously downloaded local file. If the file is absent it raises FileNotFoundError with a clear message; it does not fall back to a live fetch.

2. Data sovereignty

Each plugin is the sole authority over its own data and has no knowledge of any other source. fetch() returns only that source's canonical DataFrame. No cross-source filtering, join hints, or foreign schema references belong inside a plugin. All joining and merging is the exclusive responsibility of DataBroker.

Checklist for this PR

• components/sidebar.py does not pass cross-source context into any plugin's fetch() call
• No page triggers a network call (directly or via a plugin) during Streamlit startup or page render
• Pages with absent data show a friendly empty state (guides user to run the download step) rather than raising an unhandled exception
• Consider adding is_data_available() -> bool to the SourcePlugin ABC so pages can branch cleanly without catching exceptions

Test plan

• CI goes green (ruff, mypy, pytest 78/78)
• streamlit run visualize.py launches with sidebar nav and all existing charts intact
• Navigating between pages does not reload data from disk
• Pages with no data show empty state message rather than erroring

🤖 Generated with Claude Code

[jschloman]

Architectural note: download-then-display for all source plugins

A decision has been made (see #30) that no SourcePlugin should make outbound network calls at Streamlit runtime. All plugins must follow a two-phase model:

1. Download phase — a separate CLI script/helper fetches data from the external source and writes it to a local file in data/.
2. Display phase — SourcePlugin.fetch() reads only from that local file. Zero network I/O at render time.

Impact on this PR

Please audit components/sidebar.py and any page that calls plugin.fetch() (or DataBroker) to confirm:

• No plugin is instantiated in a way that could trigger a network call during Streamlit startup or page render.
• If the local data file is absent, the plugin surfaces a clear FileNotFoundError or empty-state message rather than attempting a live fetch as a fallback.

This may require updating the SourcePlugin ABC (from #8) to formalize the contract — e.g. adding a is_data_available() -> bool helper so pages can render a friendly "run the download script first" empty state instead of erroring.

Flagging before merge so the pattern is locked in consistently across all future plugins.

[jschloman]

Second architectural note: data sovereignty

Building on the download-then-display constraint (previous comment), a second principle applies to all SourcePlugin implementations:

Each plugin is the sole authority over its own data and must be completely unaware of any other source.

Concretely, a plugin must not:

• Reference columns, schemas, or IDs from another plugin
• Accept parameters that reflect another source's shape (e.g. a timestamp range derived from Last.fm data)
• Perform any filtering or transformation that implies knowledge of how its output will be joined

All cross-source logic — joins, merges, correlations, shared time-range filtering — belongs exclusively in DataBroker (or an equivalent orchestration layer).

Why this matters for this PR

Please check components/sidebar.py and any page that coordinates data from multiple plugins:

• Is any plugin's fetch() call parameterised by data derived from another plugin?
• Does any page pass a cross-source filter into a plugin rather than applying it after loading?
• Does DataBroker encapsulate all join/merge logic, or has any of it leaked into individual plugins?

If the SourcePlugin ABC in #8 doesn't yet enforce this boundary (e.g. via signature constraints or documentation), this PR is a good opportunity to tighten that contract before more plugins are built on top of it.