[ENHANCEMENT] Optimize time-series tooltip and panel hover rendering

[Gladorme]

Description

Split out of #319 to ease review (independent from the other split PRs, based on main).

Make hovering charts cheaper.

• New internal useChartTooltipData hook: reads the ECharts instance only for the active cursor, throttles React updates to one per animation frame, and skips the update when nearby series are unchanged. TimeChartTooltip uses it instead of a useLayoutEffect + setState on every mouse move.
• nearby-series: the sorted timestamp list (used for bar bandwidth) is only computed when bar series are present.
• PanelFocusProvider: split into an actions context and a focused-panel-key context so components that only set/clear focus no longer re-render when the focused panel changes on hover.
• Added tests for useChartTooltipData, TooltipContent and PanelFocusProvider.

Validation on this branch: npm run lint, npm run format:check, npm run type-check and npm run test all pass.

Performance, base vs. PR

I ran the same benchmark against the base version and the PR version of the changed files. The tooltip runs used the real TimeChartTooltip and getNearbySeriesData with a fake ECharts chart, 20 series × 720 points, and 300 mouse moves over one panel.

Scenario	Base	PR
30 panels: React commits	18,001	301
30 panels: getNearbySeriesData calls	9,000	300
1 panel: React commits per move	2	1
1 panel: render time	~890 ms	~420 ms
3 mouse events per frame: computations	300	100
getNearbySeriesData alone, line-only data (3 runs)	66–74 µs	26–30 µs (~2.5× faster)
50 panels, 50 hovers: re-renders of panels using the focus handlers	5,000	0

The number of ECharts highlight actions per computed frame is the same, so highlighting still happens for every frame that's computed. Timings come from jsdom, so treat them as rough. The commit and call counts are exact.

• Idle panels: TimeSeriesChartBase in the plugin starts with showTooltip=true, so every time-series panel mounts a tooltip. On base, each of them re-rendered on every mouse move anywhere on the page; now they do nothing.
• Hovered panel: the old code committed twice per move (cursor, then series). Now there's one commit per frame, and the content (TooltipContent, SeriesInfo) is skipped when the nearby series haven't changed.
• Panel focus: on base, every grid item (GridItemContent) re-rendered each time the hovered panel changed.

Screenshots

No visual change.

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
  following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

UI Changes

• Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
• Code follows the UI guidelines.
• E2E tests are stable and unlikely to be flaky.
  See e2e docs for more details. Common issues include:
  • Is the data inconsistent? You need to mock API requests.
  • Does the time change? You need to use consistent time values or mock time utilities.
  • Does it have loading states? You need to wait for loading to complete.