Build a multi-view dashboard as one self-contained Claude Artifact

Build this as a single self-contained Artifact — one React component, no external libraries beyond what the Artifact environment already provides, no network calls, no separate files. Everything below must live inside one component with shared state, not several Artifacts stitched together afterward.

DASHBOARD PURPOSE
An internal dashboard for reviewing this month's support ticket volume by category and by agent, so the team lead can spot a category spike or an overloaded agent at a glance.

DATA SOURCE
A CSV of 340 tickets with columns: ticket_id, category, agent, opened_at, resolved_at, priority — pasted in full below the prompt. Treat this as the single source of truth for every view below — do not invent additional rows, categories, or values not present in it, and if the data is ambiguous in a way that would change a chart's meaning, say so before rendering rather than guessing silently. If the dataset includes a column whose meaning is not obvious from its header alone, state your interpretation of what it represents before using it in any view, so a wrong assumption is visible rather than baked silently into a chart.

VIEWS
Build these as switchable tabs or sections within the one component, sharing the same underlying data and any filters the user sets:
Tab 1: ticket volume by category (bar chart) with a date-range filter. Tab 2: average resolution time by agent (table, sortable). Tab 3: open vs resolved ratio over the selected date range (line chart).

STATE MODEL
Hold filters, selections, and the active view in one top-level state object, not scattered per-tab local state — this is what makes cross-view consistency mechanically enforceable rather than something to remember to keep in sync by hand.

SHARED INTERACTIONS
The date-range filter set in Tab 1 must also apply to Tab 2 and Tab 3 — selecting 'last 7 days' should filter all three views to the same window, not just the one currently visible. A filter or selection made in one view must be reflected consistently if the same dimension appears in another view — do not let two tabs silently show different filtered subsets of the same data without indicating that a filter is active.

EDGE CASES TO HANDLE EXPLICITLY
An agent with zero tickets in the selected range, a category with only one ticket (can't show a meaningful average), and a date range with no tickets at all. For any of these you decide not to handle, say so in your closing note rather than letting it fail silently at runtime.

REQUIREMENTS
- Switching between views must be instant with no reload or recomputation flash — hold shared state in the component, do not refetch or reconstruct it per tab.
- Every chart or table must degrade gracefully with zero, one, or a handful of data points — no chart library error, no divide-by-zero, no empty white box with no explanation.
- Design for a narrow side-panel width first, not a full desktop screen — tabs should stack or scroll horizontally rather than get cut off, and any table must scroll inside its own container rather than forcing the whole panel to scroll sideways.
- Every interactive control (tab, filter, toggle) must be reachable and legible without relying on hover alone, since a side panel is often viewed on a laptop trackpad, not a mouse with reliable hover states.
- Do not add a view, filter, or metric beyond what is specified above, even a good one — a dashboard with one purpose is easier to trust than one that quietly grew a second job.
- Use color purposefully, not decoratively — if two categories need to be visually distinguished, the color choice should carry that meaning, not just fill space.

AFTER BUILDING
State in two or three sentences: which edge case, if any, from the list above you decided not to handle and why, and whether any part of the data source required an assumption you made on the user's behalf rather than something stated outright.