feat(uptime): 3-state uptime chart

[ankitgoswami]

Summary

• New miner_state_snapshots TimescaleDB hypertable storing one row per paired device per tick with a 4-state code (offline/sleeping/broken/hashing). Classifier CASE mirrors CountMinersByState, so the chart and the live FleetHealth legend agree.
• Uptime chart rendered as 3 segments: Hashing / Needs attention / Not hashing. Drill-through buttons deep-link to the matching miner-list filters via the existing encodeFilterToURL helper.
• Writer is a single INSERT ... SELECT per 60 s tick — one round-trip, no per-org loop, no Go-side array packing.
• Read query (GetMinerStateSnapshots) does DISTINCT ON (bucket, device_identifier) + SUM-by-state and applies the device filter at the CTE level, so uptime_status_counts honors the full device_selector (fleet, group, rack, arbitrary list). Drops in cleanly for future group/rack overview pages without server changes.

fixes #12

Test plan

• go build, go vet, golangci-lint run clean on server/internal/... and server/cmd/...
• go test ./internal/domain/telemetry/... ./internal/handlers/telemetry/... green
• Unit tests for writeFleetStateSnapshot (happy path + log-on-error) and lifecycle tests (Start/Stop) cover the tick fires
• cd client && npx tsc --noEmit, npm run lint, vitest run src/protoFleet/features/dashboard green
• Manual: bring up local stack, verify miner_state_snapshots grows by ~fleet-size rows/min, open dashboard, confirm all 3 segments render, confirm drill-throughs land on the right filter URLs, confirm totals match FleetHealth legend

🤖 Generated with Claude Code

[github-actions]

🔐 Codex Security Review

Note: This is an automated security-focused code review generated by Codex.
It should be used as a supplementary check alongside human review.
False positives are possible - use your judgment.

Scope summary

• Reviewed pull request diff only (b8945fb1b4db0f6486a33066a2640c9263246d2f...ff020b23d39417819b502028c9c0c7fa83c949a4, exact PR three-dot diff)
• Model: gpt-5.4

💡 Click "edited" above to see previous reviews for this PR.

---

Review Summary

Overall Risk: HIGH

Findings

[HIGH] Per-device minute snapshots will create unsustainable TimescaleDB growth

• Category: Reliability
• Location: server/sqlc/queries/miner_state_snapshots.sql:9
• Description: The new snapshot pipeline inserts one row per paired miner on every snapshot tick, and the migration retains those rows for one year. At the default 60s interval this is 1,440,000 rows/day per 1,000 miners, or 525,600,000 rows/year per 1,000 miners. On fleets of a few thousand miners, this becomes billions of rows, and every tick also runs a full fleet-wide join over device, device_pairing, device_status, and errors.
• Impact: Large fleets can drive sustained write amplification, compression backlog, storage exhaustion, and increasingly slow snapshot queries, eventually degrading or taking down the primary database.
• Recommendation: Store aggregated org/bucket counts instead of per-device snapshots, or record only state transitions and downsample aggressively. If per-device history is truly required, shorten retention substantially and add capacity limits/observability before rollout.

[MEDIUM] Switching uptime reads to the new snapshot table drops all pre-deploy history

• Category: Reliability
• Location: server/internal/infrastructure/timescaledb/telemetry_store.go:556
• Description: Authenticated combined-metrics reads now overwrite the old raw/hourly/daily uptime counts with uptimeCountsForQuery(), which reads only miner_state_snapshots. The new migration only creates the table and policies; it does not backfill from existing telemetry/status history.
• Impact: After deployment, any 24h/7d/30d/etc. uptime window is mostly zero-filled until enough new snapshots accumulate, and all uptime history from before the rollout is effectively unavailable.
• Recommendation: Backfill the snapshot table before switching reads, or keep the previous uptime-count path as a fallback until snapshot coverage exists for the requested window.

[MEDIUM] Historical GetCombinedMetrics requests always include a synthetic “now” bucket

• Category: gRPC
• Location: server/internal/domain/telemetry/service.go:1027
• Description: GetCombinedMetrics() now unconditionally appends a live uptime bar built from time.Now() and GetMinerStateCounts(). That happens even when the caller supplied an explicit historical end_time.
• Impact: Pull responses for past ranges are no longer time-bounded: the last uptime bar can fall outside the requested interval and reveal current fleet state in what should be a historical snapshot.
• Recommendation: Only append the live bar when the query is effectively “up to now” (for example, no end_time or end_time within one snapshot interval of now), or keep this behavior limited to the streaming endpoint.

[MEDIUM] Uptime history disappears whenever there are no metric rows, even if snapshot rows exist

• Category: Reliability
• Location: server/internal/infrastructure/timescaledb/telemetry_store.go:547
• Description: The raw/hourly/daily combined-metrics paths still return immediately on len(data) == 0 / len(rows) == 0 before they reach the new uptime snapshot query path. The same pattern repeats in the hourly and daily branches at lines 595 and 643.
• Impact: Exactly the cases the uptime panel should explain, such as fully offline fleets or filters matching miners with no recent telemetry, collapse to an empty history or only the synthetic live bar despite miner_state_snapshots containing the needed status history.
• Recommendation: Decouple uptime retrieval from metric retrieval so status-history responses can be returned even when the metric series is empty.

Notes

• I did not find new JWT handling, SQL injection, command injection, pool-hijack, or plugin-boundary issues in the changed code.
• The new tests cover device-scoped live counts and UI bucket wiring, but I did not see coverage for migration/backfill behavior, end_time in the past, or empty-metric windows.

---

_{Generated by Codex Security Review |
Triggered by: @ankitgoswami |
Review workflow run}

[flesher]

One small thing I noticed, otherwise looks good