feat: overview page comparing metrics and events across websites

[CorCvusRamboChen]

Refs #4513

Draft / RFC. This is a working prototype (running on my own instance) opened early to get
feedback, not a finished feature. Happy to rename it, move it (own page vs. Dashboard widget vs.
Boards component), trim or extend the scope, or close it if this is not a direction you want.
Suggestions very welcome.

What

Adds an Overview page that puts several websites on one chart and one table, so an instance that
hosts a family of related sites can answer "which site grew?" without opening each website page.

• src/app/(main)/overview/ — page + client component: website multi-select (defaults to every
  website the user can view), metric select (Views / Visitors / any custom event name found in the
  data), the standard DateFilter with an "All time" option, a BarChart with a chart-type toggle
  (stacked bars / lines / stacked area, one colour per website), and a totals table (views,
  visitors, one column per event name) with a column picker in the page header that is remembered
  per browser.
• src/app/api/websites/overview/route.ts — GET /api/websites/overview?ids=&startAt=&endAt=&unit=&timezone=.
  Composes the existing getPageviewStats, getSessionStats, getEventStats and
  getWebsiteDateRange per website; authorisation via canViewBatchWebsites, mirroring
  /api/websites/charts. Forbidden or unknown ids are dropped, not rejected.
• SideNav.tsx / MobileNav.tsx — one entry each, reusing the existing label.overview, label.chart and label.fields keys.

Why

Dashboard and Boards give one widget per website: independent charts with independent axes and no
stacking or totals, and no way to switch all of them to the same custom event. The Websites list's
sparkline is fixed to visitors over seven days. Comparing sites day by day currently means opening
each website in its own tab. See the linked issue for the full use case.

Open questions

• Is a dedicated page right, or should this be a Boards / Dashboard component type?
• "Overview" reuses an existing label; a dedicated label (e.g. "Compare") would mean new i18n keys.
• Should the column picker persist per user (database) instead of per browser (localStorage)?
• Cap of 20 websites mirrors /api/websites/charts; fine, or should it page?

Notes for review

• No migrations, no new dependencies, no new i18n keys. Only @umami/react-zen and Chart.js.
• Works on both Prisma and ClickHouse because the route only composes existing query functions.
• ids is capped at 20 like /api/websites/charts.
• The event-name list and the table's event columns are derived from the response, so nothing
  needs configuring per instance.
• pnpm build and pnpm lint pass; the tree has been type-checked with tsc --noEmit.

Screenshots

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[vercel]

@RamboChenUnimelb is attempting to deploy a commit to the Umami Software Team on Vercel.

A member of the Team first needs to authorize it.