Click a Top functions/models bar to jump straight to its data

[VasiliyRad]

The problem

The leaderboard-style bar charts ("Top functions", "Top models", "Spend by route", etc.) were a dead end. Long dotted/colon names truncated unreadably (agents.pipeli… instead of the identifying ..._llm_call), the only way to see the full name was a slow native browser tooltip, and there was no way to go from "this bar is expensive" to the actual calls behind it — you had to manually scroll down and find the same row again in the table below.

What this changes

You can now click any bar to jump straight to its data. From Overview, clicking a row in "Top functions" or "Top models" takes you to the matching tab with that item already selected and scrolled into view — on Functions it even auto-expands the per-function detail panel (timeseries + recent calls), since that already existed and just needed wiring up. From within a tab's own chart (e.g. Functions' "Spend by function"), clicking selects in place.

Alongside that:

• Long names truncate from the middle instead of the end, so the identifying tail (...:summarize_invoice) survives instead of being eaten first.
• A fast custom tooltip replaces the ~1s native browser one for the full name.

Implementation notes

• HBarChart gained two optional props: onSelect(key) (click-to-drill-in; the folded "other (N)" row is never clickable) and labelFor(key) (transforms only the displayed string — the underlying key stays raw so it can still be matched against a table row, which mattered for Routes specifically since it already shortens route keys for display).
• Cross-tab selection is carried via the URL hash (#/functions?select=...), reusing a convention App.jsx's router already had half-built (it already stripped ?... when matching the active tab, just wasn't using it for anything).
• Table's existing activeKey highlighting now also scrolls the row into view, via a callback ref rather than an effect — the row can still be a loading skeleton at the moment activeKey is set, so an effect keyed on it alone could fire before the DOM node exists.

Test plan

No frontend test suite exists in this repo yet (dashboard/package.json has no test script). Verified manually via a headless-Chromium script driving the actual running dev server: hover tooltip renders correctly, click-through lands on the right tab with the right row highlighted and scrolled into view across all four tabs, no console errors, and a couple of specific edge cases — clicking an already-selected row toggles it off, and reloading after closing a selection doesn't resurrect it from a stale URL.

This also went through a full review pass (architecture, edge cases, a11y) before opening — a few real issues came up (a scroll-into-view mechanism that could re-trigger on unrelated re-renders, a tooltip that could clip in narrow panels, the URL leaking a stale selection) and are already fixed and re-verified here, not left as follow-ups.

🤖 Generated with Claude Code