feat(charts): drag-to-zoom, fullscreen expand, timezone-aware time controls

[JeremyFunk]

Time-range UX for the dashboard, service-detail, and home-overview charts. (Arrow-key keyboard navigation is split into a follow-up PR stacked on this one.)

What's included

• Drag-to-zoom — drag across any time-series chart to narrow the window to that selection. Click vs drag is decided by pointer travel (≥6px), so a plain click never zooms. Shared useChartDragZoom hook drives all chart types; read-only history previews don't mutate the live range.
• Expand to fullscreen — a maximize button (revealed on card hover) opens any chart in a near-fullscreen centered modal (ChartExpandModal). Also fixes the pre-existing widget-header hover-reveal (a group/card class was never declared, so actions only appeared after a click) and the action-button alignment.
• Timezone selector — the time-range picker footer is now a searchable popover: search by zone name or UTC offset, "System" and "UTC" pinned first, sorted, with aligned offset columns.
• Timezone-correct chart times — x-axis ticks, tooltips, and deploy-marker times render in the user's selected timezone (threaded through formatBucketLabel), not the browser's. Incoming buckets are normalized to UTC upstream, so re-projection is correct for any source offset.
• Custom-range fix — selecting a custom range no longer jumps by the UTC offset (timezone-aware round-trip); a reversed start/end is ordered ascending.

Notes

• Base PR of a stack; the keyboard navigation PR (arrow-key pan/zoom + F-to-expand) targets this branch.
• Verified end-to-end in-browser across all three surfaces. bun typecheck at the branch baseline (web 23 pre-existing, ui 0); lint/format clean.

🤖 Generated with Claude Code

[pullfrog]

ℹ️ No critical issues — one minor suggestion inline.

Reviewed changes — the initial Review of the time-range UX work (drag-to-zoom, fullscreen expand, and timezone-aware time controls) across the dashboard, service-detail, and home-overview charts.

• Add useChartDragZoom — a shared Recharts gesture hook in packages/ui driving drag-to-zoom on all 7 time-series charts, with a 6px click-vs-drag threshold and ascending-ordered onZoomSelect payloads.
• Thread onZoomSelect end-to-end — new BaseChartProps.onZoomSelect, wired through chart-widget/metrics-grid into routes/index.tsx, routes/services/$serviceName.tsx, and dashboard-canvas (gated off in readOnly), with zoomRangeToWarehouse converting buckets and no-op'ing degenerate selections.
• Add ChartExpandModal + renderExpanded — a near-fullscreen chart modal exposed via a render-prop on WidgetShell/WidgetFrame/MetricsGrid; also repairs the pre-existing group/card hover-reveal and action-button alignment.
• Rebuild the timezone selector — timezone-display.tsx becomes a searchable popover (search by zone name or UTC offset, System/UTC pinned, offset-sorted) backed by formatZoneOffsetLabel/getZoneOffsetMinutes.
• Timezone-correct labels and custom range — formatBucketLabel gains a timeZone param threaded through every tick/tooltip/deploy-marker; custom-range-picker round-trips wall-clock ↔ UTC via new timezone-format helpers (zonedWallClockToUtc/utcToZonedWallClock), and $serviceName.tsx drops the "12h" preset default so the custom-range indicator lights up after a zoom.

The timezone math holds up under scrutiny: the single-pass zonedWallClockToUtc correction is correct for fractional-offset zones (+5:30, +5:45, +12:45/+13:45), and the only approximation is the unavoidable DST ambiguous/skipped hour, which is documented in-code. Bucket values reach formatBucketLabel as Z-suffixed ISO instants, so the toLocaleString({ timeZone }) re-projection does not double-shift on the live data path. The drag-zoom state machine is robust — leave/up double-commit is idempotent, synced charts don't cross-fire the gesture, and non-parseable labels degrade to a no-op. The presetValue default removal on the service-detail route is a deliberate, correct enabler for the custom-range indicator rather than a regression.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

ℹ️ renderExpanded() is invoked on every WidgetShell render, even while the modal is closed. The chart is only mounted when open (ChartExpandModal renders {open ? children : null}), but the element returned here is still allocated each render — which the renderExpanded JSDoc ("only mounted while the modal is open") implies should be lazy. The allocation is shallow (the discarded subtree isn't reconciled), so this is a minor polish item, not a correctness issue.

Technical details

# Eager `renderExpanded()` call defeats the documented laziness

## Affected sites
- `apps/web/src/components/dashboard-builder/widgets/widget-shell.tsx:212` — `{renderExpanded()}` passed as `children` to `ChartExpandModal`, evaluated every render.
- `apps/web/src/components/dashboard/metrics-grid.tsx` — `renderExpanded` is a new closure per render wrapping `<Suspense>{renderChart(true)}</Suspense>`, so the element tree is rebuilt on each `MetricsGrid` re-render (e.g. on syncId hover).

## Required outcome
- The expanded-chart element tree should not be constructed until the modal is open, matching the `WidgetShellProps.renderExpanded` contract.

## Suggested approach (optional)
Guard the call by `expanded` at the call site (`{expanded && renderExpanded()}`) or move the invocation inside `ChartExpandModal` so it runs only on the `open` branch.

[Makisuo]

@pullfrog resolve conflict

[pullfrog]

Resolved the merge conflict from main into feat/chart-time-range-ux. The only conflict was in apps/web/src/routes/services/$serviceName.tsx, where both branches added a distinct property to the same widget-metrics object literal — kept both onZoomSelect (this branch) and isLoading: isDetailLoading (main); the MetricsGrid item type supports both. Merge committed and pushed. Remaining bun typecheck errors are pre-existing in packages/query-engine (missing @maple-dev/clickhouse-builder build artifacts) and unrelated to this resolution.

Task list (4/4 completed)

• Checkout PR branch and identify base branch
• Fetch base branch and attempt merge
• Resolve conflicts if any
• Verify, commit, push, report

  ^{｜ View workflow run ｜ via Pullfrog ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes — the delta since the prior pullfrog review (edb7c1c/5a744aa): the main-merge b836acf pulled the keyboard-navigation feature (537c0022, PR #106) into this branch.

• Add useTimeRangeKeyboardControls — new apps/web/src/hooks/use-time-range-keyboard.ts registers arrow-key pan/zoom over the resolved absolute window (Left/Right pan, Up/Down zoom around center; Shift = larger step, Ctrl/Meta = fine), single-pass-clamped into [now − 2y, now] with a 60s minimum width and a no-op guard that avoids history churn.
• Wire keyboard controls into three surfaces — routes/index.tsx, routes/services/$serviceName.tsx (overview tab only), and routes/dashboards/$dashboardId.tsx (DashboardRefreshBridge, fed resolvedTimeRange), each writing an absolute range back with replace so rapid presses don't stack history.
• Add isOverlayOpen and the F-to-expand hotkey — lib/keyboard.ts gains isOverlayOpen() (dialog/menu/listbox [data-open]) so page-level shortcuts defer to overlay navigation; widget-shell.tsx adds an F hotkey gated on per-card hover/focus plus tabIndex focus tracking with an onBlur containment check.

The keyboard math holds up: applyKey/clampToBand use mutually-exclusive clamp branches (no edge leak), floor width at MIN_WINDOW_MS, and return null on no-ops. The hook's inputs (effectiveStartTime/effectiveEndTime and the dashboard resolvedTimeRange) are all warehouse-format absolute strings, so parseMs → normalizeTimestampInput is correct. Capital-letter hotkey strings ("F") map to the plain key rather than a Shift combo, matching the established "J"/Shift+X convention in use-list-navigation, and the new arrow-key registrations don't collide with useListNavigation (which only mounts on the errors/issues, anomalies, and traces-table routes — disjoint from the three keyboard-nav surfaces). The prior eager-renderExpanded() note is unchanged by these commits and remains open.

ℹ️ Keyboard nav merged in despite being described as a stacked follow-up

The PR body states arrow-key keyboard navigation is "split into a follow-up PR stacked on this one," but the b836acf merge of main pulled that follow-up (537c0022, PR #106) into this branch, so it now ships as part of #105. This isn't a defect — the merge is clean and the feature reviews well — but the scope of this PR has grown beyond what its description advertises.

Technical details

# Keyboard-nav scope now exceeds the PR description

## Affected sites
- PR #105 description ("Arrow-key keyboard navigation is split into a follow-up PR stacked on this one") vs. the `b836acf` merge that landed `537c0022` (PR #106) on `feat/chart-time-range-ux`.
- `apps/web/src/hooks/use-time-range-keyboard.ts`, `apps/web/src/lib/keyboard.ts`, `apps/web/src/components/dashboard-builder/widgets/widget-shell.tsx`, and the three route files now carry the keyboard-nav feature.

## Required outcome
- Confirm the intent: either keyboard nav is meant to ship inside #105 (update the description so reviewers and the changelog reflect the real scope), or the merge accidentally absorbed the follow-up and it should be excluded from this branch.

## Open questions for the human
- Was PR #106 intended to merge into `main` independently, or to remain stacked? If stacked, merging #105 now also merges the keyboard-nav work.

  ^{｜ ⚠️ this action is pinned to a commit SHA, which freezes the cleanup step — switch to @v0 or keep the SHA fresh with Dependabot ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}