Store share stats as time-series for reject-rate trends/charting

[VijitSingh97]

Background

#82 (PR #109) surfaced per-worker accepted / rejected / invalid share counts and the pool-wide xmrig-proxy /summary totals (accepted/rejected/invalid/expired + best difficulty) in the dashboard.

That data is persisted only as a latest-state snapshot — it rides along in the latest_data blob saved to the kv_store table under snapshot_latest_data (overwritten every cycle), so the dashboard repopulates it immediately after a restart. The only time-series table is history, which stores hashrate only (v / v_p2pool / v_xvb / timestamp).

Problem

Because share stats aren't recorded as a per-timestamp series, we can't show a trend — e.g. chart reject rate over the last 24h, or compute a rejects-per-hour rate to catch a rig that's slowly degrading. Right now an operator only sees the current cumulative totals.

Proposal

Persist share stats as time-series so the dashboard can chart/trend them.

Open questions to settle in the issue:

• Granularity — pool-wide totals only (cheap), or per-worker series too (more useful for isolating one bad rig, but higher row volume).
• Schema — add columns to history, or a dedicated share_stats table (cleaner: independent retention, and avoids multiplying history rows if we go per-worker).
• Cumulative-counter handling — the proxy reports counts cumulative since it started, so a meaningful per-interval rate needs deltas between consecutive samples. A proxy restart resets the counters to 0, which makes a naive delta go negative — that must be detected and treated as a reset (segment break), not a negative rate.

Acceptance criteria

• Share stats stored as a time-series (at minimum pool-wide accepted/rejected/invalid; ideally per-worker).
• Per-interval rate derivation handles proxy counter resets (restart → reset, not a negative delta).
• Trend exposed in the dashboard (a reject-rate chart/sparkline, or at least the series available in /api/state for the client to render).
• Retention + pruning consistent with the existing history policy (HISTORY_RETENTION_SEC).
• Tests at the storage + view layers.

Pointers

• build/dashboard/mining_dashboard/service/storage_service.py — update_history / save_snapshot; the history and kv_store tables.
• build/dashboard/mining_dashboard/service/data_service.py — _parse_proxy_summary, run loop where proxy_summary + per-worker counts are assembled.
• build/dashboard/mining_dashboard/web/views.py — build_proxy_summary, build_workers, build_chart.

Follow-up to #82.

Telegram integration (v1.2 bot follow-up, #341)

Added to acceptance criteria — the operator bot (#121/#45) already has the plumbing:

• Telegram: push a high_reject_rate alert (per-event toggle, debounced) when the pool-wide reject rate exceeds a configurable threshold over the trend window, reusing the per-interval reject rate this issue derives.

[VijitSingh97]

Folded into the telemetry-persistence audit/epic #196 as the pool-wide (and per-worker stretch) share-health slice. Design + implementation stay here; the epic tracks the shared persistence approach (dedicated tables, retention, reset-safe deltas) and the other discarded series (block events, disk-growth, XvB credited history, per-worker history).