Periodic traffic report is not informative and never changes in Telegram bot

[rvalitov]

Type: enhancement
Area: Telegram bot / telemetry
Addressed by: PR 4 of 4 (feat(telegram): traffic history, analytics and an informative periodic report)

Summary

The periodic report sends the same three facts every interval, regardless of
whether anything happened:

📊 Periodic Report

🟢 Running | ⏱ 12d 4h
👥 Connections: 37
📊 ↓ 18.4 GB ↑ 4.1 GB

The two traffic figures are lifetime cumulative counters. They only ever
increase, so the report is monotonically less informative the longer the server
runs, and it cannot answer the question an operator actually has.

Impact

• "How much did we move today, and is that more or less than yesterday?" is
  unanswerable. The only numbers shown are since-the-beginning totals.
• The message is identical every time when idle. A server with no traffic
  still produces a full report every interval, training operators to ignore it —
  which defeats the purpose of the alert channel.
• No visibility into per-user trends. /mp_traffic shows cumulative totals
  per user, which have the same problem: a user who transferred 5 GB last month
  and nothing since looks identical to one who transferred 5 GB this morning.
• Quota and expiry problems are only surfaced at the moment of enforcement.
  The report gives no early warning that users are approaching their limits.

Root cause

Nothing records how usage changes over time. relay_stats/ holds a running total
plus a single "last raw values" snapshot used only for delta arithmetic. There is
no history, so no windowed or comparative figure can be computed.

Proposal

1. Record a rolling history of coarse samples (5-minute, 7-day retention) per
   user and globally, under relay_stats/history/. Store deltas, not
   cumulative counters, so an engine restart or a traffic reset cannot corrupt
   a window that spans it.

2. Derive windowed analytics from it: 24h/7d/30d totals, period-over-period
   change, peak and average rate, top talkers, an hourly sparkline, quota
   pressure and expiry watch.

   Peak should use the actual gap between samples, not the nominal interval,
   so a daemon outage reads as a real gap rather than a phantom spike. Average
   should divide by the span actually covered.

3. Make the report activity-aware. With no traffic in the window it should
   collapse to a one-line heartbeat rather than repeat a dashboard of zeroes. A
   verbosity setting should allow forcing either behaviour.

4. Expose management commands for the new store: status, prune, reset.

5. Reuse the existing 80/100 quota thresholds and the existing ISO expiry
   parser for the warning lines, so the report and the enforcement loop cannot
   disagree.

Acceptance criteria

• The report shows windowed (e.g. 24h) figures, not just lifetime totals.
• Period-over-period change is shown, and reads n/a when there is no
  previous window (never inf/nan, and never a numeric sentinel that a
  genuine small decrease would collide with).
• An idle window produces a heartbeat, not a full report.
• Peak rate reflects the real inter-sample gap.
• History survives proxy restarts and traffic resets without corrupting
  windows.
• Retention is applied automatically, and pruning is idempotent.
• History keeps recording while the Telegram bot is disabled.
• The report flags users at ≥80% quota and secrets expiring within 3 days.

Notes

Cumulative counters should remain available — operators rely on them — but they
should not be the whole report.