improve statistics page

[slothful-vassal]

Statistics page: completed trails as activities

Trails you mark as completed without writing a summit log were missing from your statistics. They now show up as normal activities — in the totals, the calendar and the table — and a trail that already has a summit log is still counted once.

Also new on the page: quick period presets (month, quarter, year, last 12 months) plus a free date range, a calendar you can still browse independently of the selected period, and an activity chart that switches between days, months, quarters and years depending on how much time you're looking at. Category colours are now consistent between chart, calendar and table.

Tests

• Migration on an existing DB: previously completed trails get a plausible completed_at, statistics counts stay unchanged where a summit log exists.
• Completed trail without a summit log appears in count, totals, calendar and table.
• Trail with a summit log is counted once, not twice.
• Toggling completed off clears the date; toggling it on prefills the oldest summit log date, or today when there is none.
• Each period preset and a custom range: chart granularity and axis labels adapt, the last day of the range is included.
• Calendar month navigation loads that month independently of the period; Days with multiple activities are shown in multiple colors.
• Uncategorized trail: coloured consistently in pie chart, calendar and table.
• Plugin import of a completed activity sets completed_at from the import date.
• Federated profile statistics still resolve (photo/GPX URLs point at the origin).

Screenshot

[Flomp]

Thanks! An update for the stats page was long overdue. This is a great start!

1 & 2: Pie chart crashes when changing the period (unrelated to PR). Selecting a preset threw can't access property "syncEventHandler", chart.crosshair is undefined and the pie chart stopped rendering.

Root cause is the vendored elevation profile registering chartjs-plugin-crosshair globally via Chart.register, so it attached to every chart in the session.

• Extended the existing afterDraw guard to cover afterDestroy, afterEvent and beforeTooltipDraw elevationprofile.ts#L26
• Replaced the global Chart.register with an entry in the elevation chart's own inline plugins array, so unrelated charts never see it at all: elevationprofile.ts#L698

3: Migration backfill was two queries per completed trail. The record loop ran a summit_logs query plus a Save for every completed trail, all blocking startup. Replaced with two set-based statements: 1786350000_add_trail_completed_at.go#L46 and #L64. There's no index on summit_logs.trail, so the oldest dates are grouped once and joined on the trails primary key rather than looked up per trail (EXPLAIN QUERY PLAN confirms a single materialized scan).

4: Dropped the unused summit_logs_via_trail expand. stats/+server.ts#L119 was expanding every completed trail's full summit-log set into the response, but mergeStatisticActivities deduplicates only against the summit logs from the filtered query and deliberately ignores the expand.

---

Question about the calendar. The docs say: "Moving to another month in the calendar updates this date range automatically" (statistics.md#L10), but the code does the opposite: handleCalendarMonthChange only updates calendarRange and refetches calendarActivities; filter.startDate/endDate are untouched. So scrolling the calendar doesn't change the filter range at all, which matches the PR description ("browse independently of the selected period") but not the docs.

Related: no onclick is passed to <Calendar> (#L787), so disabled={!day || !onclick} (calendar.svelte#L195) makes every day cell a disabled button. Clicking a day used to set the range to that day; now it does nothing, though the cells still look clickable.

What's your intent here? should the calendar stay fully independent (and the docs line get dropped), or should navigating/clicking drive the filter? Happy to go either way, just want the docs, the UI affordance and the code to agree.