fix(pricing): bill whole Beijing weekends off-peak for DeepSeek V4 - #505

What's wrong

The derived DeepSeek tier — isDeepSeekOffPeak in src/lib/pricing/index.js,
and the hand-copied getRowPricing in all five edge patches — decides from the
UTC hour alone. DeepSeek's pricing page now says:

Effective 00:00 (Beijing Time) on Sunday, August 23, 2026, we will adjust our
peak/off-peak billing rules … with off-peak rates applying throughout the day
on weekends (Saturdays and Sundays, Beijing Time)

That instant is 2026-08-22T16:00Z — already past. So rows whose hour_start
falls in 01:00–04:00 or 06:00–10:00 UTC on a Beijing Saturday or Sunday are
still priced at peak, while DeepSeek bills off-peak. Off-peak is exactly half, so
those hours read 2× — in account daily, summary, model breakdown, leaderboard
list and leaderboard profile alike.

The first window this gets wrong is 2026-08-23 01:00–04:00 UTC (Beijing
Sunday 09:00–12:00).

An explicitly stored pricing_tier still wins, unchanged — this only touches the
derived path.

The part that is easy to get subtly wrong

The weekend is bounded in Beijing time, not UTC: 16:00Z Friday to
16:00Z Sunday. new Date(timestamp).getUTCDay() marks a different 48 hours, so
the instant is shifted by +08:00 first. China has had no daylight saving since
1991, so the fixed offset is exact and needs no tz database.

To be straight about how much that costs today: nothing. The two peak windows sit
entirely outside the 16 hours where the two spellings disagree, so both currently
return the same tier. It is not a live bug — it is a trap that arms itself if the
windows ever move. I did it the right way round anyway and said so in the comment.

Changes

• src/lib/pricing/index.js — isBeijingWeekendOffPeak, consulted by
  isDeepSeekOffPeak before the hour check.
• The five dashboard/edge-patches/*.ts — the same block, byte-identical, per
  the copy discipline in test/edge-pricing-parity.test.js.
• test/pricing.test.js — seven assertions on computeRowCost inside the
  existing #491 test: a Beijing Saturday before the rule takes effect that
  must still be peak, the first Sunday window it flips, a Beijing Monday, a
  Friday, a later Saturday, and an explicit pricing_tier: "peak" that must
  still override.
• test/edge-pricing-parity.test.js — asserts all five files carry the effective
  instant and the +08:00 shift, and adds a real byte-identical parity check
  on getRowPricing. That function was only substring-checked before, so one
  file's window could drift while every assertion still passed — the same failure
  mode the MODEL_PRICING parity test exists to catch.

Verification

node --test test/pricing.test.js test/edge-pricing-parity.test.js
# 54 pass, 0 fail

Full npm test is 2328 tests / 2290 pass / 32 fail — identical with and
without this patch (I checked by stashing). Those 32 are MODULE_NOT_FOUND and
TS2307 from an environment without npm install run; none are in the pricing
or edge-parity files.

Summary by CodeRabbit

• New Features

  • DeepSeek V4 pricing now recognizes Beijing-local Saturdays and Sundays as off-peak starting August 23, 2026.
  • Weekend usage receives the existing 50% off-peak rate across dashboards, summaries, leaderboards, and account breakdowns.
  • Pricing correctly handles the UTC-to-Beijing time boundary while preserving explicit pricing tiers and weekday peak rules.

• Tests

  • Added coverage for weekend pricing, boundary times, weekday peak periods, and pricing-tier precedence.
  • Added consistency checks to ensure pricing behavior matches across dashboard views.