Refactor server card metrics display and cycle-traffic logic

[fl0w1nd]

TL;DR

Home-page cards reported a single "total traffic" figure that is really the agent's since-boot counter, so it silently resets whenever an agent restarts and never lines up with a billing cycle. This separates that counter from real per-cycle usage pulled from the panel's cycle_transfer_stats and renders it as a dedicated bar with percentage and window (e.g. DMIT: 507 GB / 1.0 TB (50%), 6/5 → 7/5).

Files to review

File	Why
src/lib/cycle.ts (new)	Entry point. Fetches /api/v1/service and flattens cycle_transfer_stats into a serverId → usage map.
src/components/ServerCard.tsx	Card redesign: separates since-boot total from the cycle bar, adds the period range, iconized segmented bars.
src/components/UsageBar.tsx	Shared segmented bar driven by a per-metric icon and tone.
src/components/ServerRow.tsx	List-view parity: compact cycle indicator.
src/pages/Home.tsx	Wires the cycle map and the height-reservation flags.
src/pages/Services.tsx	Reset date fix (see Reviewer notes).
src/types/nezha.ts	ServerCycleInfo shape.

Why

Nezha agents expose cumulative transfer counters that zero out on restart, so the old "total" was neither lifetime nor cyclic. The panel already persists true per-cycle usage through transfer_*_cycle alert rules and exposes it on /api/v1/service, but that data was only surfaced on the Services page. Server cards are where users actually watch quota, so the cyclic figure belongs there.

How

useCycleTransferMap reads cycle_transfer_stats (keyed by alert rule, then by server) and flattens it to one entry per server. Home builds the map once and passes each server its slice plus a reserveCycle flag; cards without a matching rule still reserve the slot so a mixed fleet stays vertically aligned. The card then draws two distinct rows — since-boot total and the cycle bar — and the segmented UsageBar carries the metric icon and color.

Reviewer notes

• The cycle bar only renders for servers covered by a transfer_*_cycle alert rule; everything degrades gracefully to the since-boot total when no rule exists.
• Reset date now uses cycle.to (the cycle end). next_update is an internal recompute timestamp and was the source of the wrong "resets 6/29" display on a cycle that actually ends 7/5.
• public_note traffic strings (e.g. 1TB/Month) stay a display-only plan tag — they are free-form and not parsed into the quota bar.
• Adds lucide-react; removes the unused Sparkline component.

Before / after

	Before	After
Transfer	one "total" line (since boot, resets on restart)	since-boot total and real cycle bar with % + period range
Bars	flat fill	segmented bars with per-metric icon and color
Reset date (Services)	internal next_update → wrong (6/29)	cycle end to → correct (7/5)

Tests

pnpm lint, tsc -b, and pnpm build pass. Verified against a live panel (NEZHA_BACKEND=…): the cycle bar, percentage, and 6/5 → 7/5 window render on cards with a configured rule, and the Services page shows the correct reset date.