Phase 3 chronology view: Timeline renders event log with bbox sync, no backend changes

rmerk's Phase 3 adds a Timeline view at `/projects/[id]/timeline/[docId]` that renders the Phase 2 event log as a sortable, citation-linked chronology. The roadmap set a hard gate - under two seconds, no LLM call - and this satisfies it by reading an existing endpoint with no new backend code or migrations.

The project page entry point branches on extraction state: one extracted PDF routes directly to Timeline, multiple PDFs open a picker, zero PDFs fall back to the existing tabular-create modal. The frontend's event type was widened to expose provider, provider_role, episode_of_care, and key_date_role fields that the backend already returned but the TypeScript type hadn't surfaced.

§ 144.293 mental-health records are hidden behind a header toggle as defense-in-depth, even though the backend already excludes peer-review records at the SQL layer. The commit is explicit about the rationale: events of that class should not be displayable, and a frontend guard is cheaper than trusting that the SQL filter is the only protection.

The earlier Rail B plan was ruled out during design. The original roadmap proposed tagging schemas like MAR and vitals as eventLogBacked and populating tabular cells from event-log SQL. The problem is that tabular_cells is keyed (review_id, document_id, column_index) - one cell per document per column. A document with 200 medication-administration events can't be represented in that model without collapsing all 200 rows into a single cell, which makes sorting and per-event inspection impossible. MAR, vitals, and labs are deferred to Phase 3.5 as separate Timeline-style views with different column lenses.

The commit notes that manual end-to-end verification against a real extracted document was not completed by the agent. Build and lint are clean; the test plan flags heap profiling and a live Epic ebook run as remaining manual work.