[paragmore]

Project Financials phase tabs take 13-17s to render (Total Site ~6s). Each tab fires three revenue-summary windows plus a metrics/hashrate interval=1d call over 12 months, and almost all of that work was repeated on every request: the 1d hashrate series rebuilt ~8,760 hourly buckets (plus a year of pool samples with pool=true) per call, and a phase revenue-summary re-fetched the whole-range by-meter series and manual consumption log every time by design. The concurrent windows then each re-scanned the same cold months independently.

This reuses the pattern the 1M rollup already has. getHashrate interval=1d caches day rows month by month (ended, fully covered months only; edge slices and the running month always recompute; overwriteCache refreshes). Phase consumption caches its hourly rows per UTC month, and saveEnergyConsumption drops that cache on a confirmed write, so manual edits are never served stale; store-side backfills are bounded by the same 12h TTL the other monthly rollups accept. getDailySeries additionally single-flights per-month rollups so the overlapping windows a tab fires at once compute each cold month once. The phase revenue-summary keeps its always-refresh semantics, so coverage/missing-hours accounting is unchanged - only the fetch underneath got cheap.

One side effect worth calling out: phase consumption now fetches per month, so months at or after energyRollup.sinceTs read the energy-1h rollup even when the request started before it, where previously one pre-rollup start forced the whole span onto the legacy stat path. The two sources are meant to agree; the rollup is the higher-fidelity one.

Bench on the real handler stack against a simulated ork (span-proportional, serialized latency; responses byte-identical before/after): warm tab renders drop from ~12s/31s/8s to ~4s/7s/4s for total/phase1/phase1_5, and cold renders improve ~25% from the single-flight dedup. Full unit and integration suites pass; new tests cover the caches (scope keys, edge months, running month, tombstones, pool rows, invalidation, concurrent dedup, failure retry).

[paragmore]

Pushed a hardening pass after a deeper review and a differential QA run (develop vs this branch driven through ~200 randomized scenarios - timezones, data gaps, phases, concurrent window bursts, manual writes between reads - with every response deep-compared).

Fixes folded in:

• A window ending exactly on a month boundary leaves a zero-width edge month once its neighbours are cached. The month rollups rejected it with ERR_INVALID_DATE_RANGE on the repeat request, and getDailySeries silently dropped the boundary hour on a warm cache while keeping it on a cold one (that inconsistency predates this PR - the single-flight just made it easier to hit). All four sites now step the degenerate span back one millisecond, which cannot add a bucket, so warm and cold answers are identical.
• A phase-hourly fetch that straddled a manual consumption write could re-store its pre-write rows after the invalidation and mask the correction for the TTL. Clears now bump a generation; a straddling fetch still answers its own request but no longer stores, and a request arriving after the write reads fresh instead of riding the stale in-flight promise.
• Adjacent cold phase months now fetch as one span per contiguous run instead of one query pair per month, so a cold 19-month window is two reads, not thirty-eight.

The differential run is clean apart from the boundary-window case above, where develop itself returns different answers for the same query depending on cache warmth and this branch consistently returns the cold (complete) one. Full unit and integration suites pass; new tests cover the boundary windows, the write-vs-fetch race, and the run batching.