web: redesign the economics page around monthly stats instead of per-epoch

[SinaVafadar]

cc @SinaVafadar @martinsander00

Follows #786.

Problem

The Edge Economics page runs on two clocks. Seat revenue is charged per epoch (~2 days, and epochs straddle month boundaries), while feed-subscription revenue is allocated per calendar month. #786 deliberately kept the two grains apart rather than converting one into the other, because dividing a month total by epochs-in-month would put a modelled figure next to observed ones. That was the right call for that PR, but it leaves the page with two units that cannot be added together, and with the business-facing half expressed in the unit nobody outside the protocol thinks in.

Everything the page is actually used for is monthly: invoices are monthly, feed subscriptions are monthly, the on-chain feed-subscription program allocates by calendar month, and the MRR and ARR tiles already imply months while being derived from epoch figures. An epoch is a Solana implementation detail.

Proposal

Redesign the page around calendar months, keeping epoch granularity as a drill-down for ops rather than the headline.

• Revenue per Epoch → Revenue per Month. Aggregate seat charges into calendar months. Epoch boundaries do not align with month boundaries, so a decision is needed: assign each epoch's charge to the month containing its end, or prorate it across the two months it spans. Prorating matches what the feed-subscription program already does on chain.
• Active Subscribers per Epoch → per month. Distinct seats active during the month.
• MRR and ARR from observed monthly totals rather than an epoch figure multiplied out.
• One monthly revenue total with a breakdown by source (seats, feed subscriptions) once both are on the same grain, which is the thing that cannot be shown today.
• Keep the epoch series behind a toggle or on a drill-down. Per-epoch remains the right view for oracle and settlement debugging.

Constraints found while building #786

• Feed revenue's month is an allocation, not cash received. The program splits one payment across the calendar months the subscription covers: solana-shreds-full-ams shows 1,887.096773 in August and 2,612.903227 in September, which is one 4,500.00 payment split 13/31 and 18/31. A combined monthly figure has to pick cash-basis or allocation-basis and label it, and the two will disagree for any mid-month purchase.
• The current month is always partial, and with allocation-basis so is the next one. indexer,api,web: show feed-subscription revenue on the economics page #786 dims those bars and labels the tiles accordingly; a monthly redesign needs the same treatment applied consistently across every panel.
• The per-epoch series comes from snapshot history (dim_dz_shred_client_seats_history), not from a fact table. Any environment whose snapshot history is short renders a misleading series rather than an empty one: the indexer,api,web: show feed-subscription revenue on the economics page #786 preview showed 2 to 14 active seats per epoch against production's 120 to 145, purely because that cluster held a single snapshot. Monthly aggregation inherits this, so the series should be clamped to the range snapshots actually cover, with the boundary stated.
• Epoch-to-time mapping needs a source of truth for epoch boundaries in order to do any month bucketing at all.

Out of scope

Changing how revenue is charged or allocated on chain. This is a presentation change over data we already index.