fix(common): honor DeepSeek Beijing weekend boundaries

[c8dhjp4tyv-bit]

Fixes #1090

Summary

• Export and directly test the Beijing weekend predicate at the Friday/Sunday UTC boundary.
• Apply DeepSeek's weekend off-peak rule only from its effective instant, 2026-08-22T16:00:00Z.
• Keep historical pricing and expensive-window checks from retroactively treating pre-change weekends as off-peak.

Why

The existing weekend tests used instants where UTC and Beijing were already on the same weekend day, so removing the +8 hour conversion left the suite green. The new boundary cases pin Friday 16:00Z and Sunday 16:00Z, where the calendars diverge.

Verification

• bun test common/src/__tests__/freebuff-peak-hours.test.ts — 26 passed
• bun run --cwd common typecheck — passed
• Prettier check and git diff --check — passed

The full common test command cannot pass in this public checkout because several existing tests reference private/web files absent from the mirror; the changed test file passes independently.

Ran the two functions from this PR, copied verbatim, against our dated vector table for the live DeepSeek schedule. 15 of 15: 12 phase vectors and 3 next-change vectors, including both effective instants and both weekend edges. Over the week beginning 2026-08-24T00:00Z it yields 35 peak hours (5 days × 7), which is the shape the vendor footnote describes.

Mutation results, since #1090 was about tests staying green:

removed	vectors broken
the >= DEEPSEEK_WEEKEND_OFFPEAK_EFFECTIVE_AT_UTC gate	2 of 12 — 2026-08-22T01:30Z and 2026-08-22T09:59:59Z, the pre-rule Saturday that must still bill peak
the + 8 * 60 * 60 * 1000 Beijing shift	0 of 12

That second row is the interesting one, and I think this PR gets it right for a reason worth writing down. With the current windows the weekend rule can only change the answer during 01:00-10:00 UTC — everywhere else the hour check already returns off-peak, so the weekend branch is a no-op. And 01:00-10:00 UTC is entirely inside the region where the UTC date and the Beijing date agree. So no vector expressed as a billing outcome can distinguish getUTCDay() from the Beijing-shifted day. Not ours, not any that can be written from the published card. That is precisely why both of the old tests stayed green.

Exporting isBeijingWeekend and asserting on it directly is the way out, and the four instants chosen here are the right four — 2026-08-28T16:00Z and 2026-08-30T16:00Z are exactly the two edges where the calendars diverge. Two of those four fail if the shift is removed. Our own answer to the same problem was to carry a synthetic schedule with a peak window past 16:00 UTC; testing the exported predicate is simpler and needs no fixture, and I would rather have it this way round.

One note, not a request: the +8 is safe here because China has observed no DST since 1991, so a fixed offset and Asia/Shanghai cannot diverge. That is a property of this one zone rather than of the code, so it may be worth a word in the comment next to the constant — the same function pointed at a zone with DST would be wrong twice a year.

Vectors are CC0 if they are useful in the suite: https://github.com/xyzs996/deepseek-peak-hours. Thanks for picking this up so quickly.

The Beijing-weekend boundary tests are a genuine improvement — the old test data (e.g. 2026-08-29T02:00:00Z) never actually exercised the +8h conversion since UTC and Beijing agreed on the day-of-week, so the new Friday-16:00Z / Sunday-16:00Z cases in freebuff-peak-hours.test.ts catch a real gap. Exporting isBeijingWeekend for direct testing is also reasonable.

The part that needs work is DEEPSEEK_WEEKEND_OFFPEAK_EFFECTIVE_AT_UTC = Date.parse('2026-08-22T16:00:00Z'). This is a brand-new piece of business logic — it changes production pricing/availability behavior for every timestamp before that instant — and nothing in the PR or the doc comment cites where this date comes from. The existing doc comment only references api-docs.deepseek.com for the peak-hour windows; there's no equivalent source for "the weekend rule took effect on 2026-08-23 Beijing time." Before this lands anywhere, that constant needs a link to the actual DeepSeek announcement, changelog, or issue #1090's description that establishes the date — otherwise this is inventing pricing policy rather than fixing a bug in existing policy.

Also: deepseekPricingWindow and isDeepSeekExpensiveWindow now both gate on the same effective-date check independently. If this constant is legitimate, it'd be worth extracting a single isWeekendOffPeakEligible(at) helper instead of duplicating the >= EFFECTIVE_AT && isBeijingWeekend(at) condition twice.

Please link the source for the effective date, or explain in the PR body what #1090 actually reported (was pricing wrongly applied retroactively? did DeepSeek publish a change date?). Without that, this can't be safely ported into a billing-adjacent codepath.

Addressed the review points in 28179bc.

• The effective instant is now explicitly sourced in the code comment: issue Both weekend tests stay green if the Beijing shift is removed #1090 records the DeepSeek Models & Pricing notice stating the weekend rule becomes effective at 00:00 Beijing time on 2026-08-23, and the comment links the current vendor pricing page (https://api-docs.deepseek.com/quick_start/pricing/) for the resulting Monday-Friday peak rule.
• Extracted isWeekendOffPeakEligible(at) so the effective-date + Beijing-weekend condition has one source of truth instead of being duplicated in both pricing/availability functions.
• Kept the direct Beijing boundary tests and the historical effective-date coverage unchanged.

Apologies — this PR was auto-closed by GitHub when we force-pushed a history rewrite of this repository (repository maintenance; every commit SHA changed). That was not a judgment on this PR, and GitHub does not allow us to reopen it because the commits it was based on no longer exist in the new history.

If you'd like to continue with this change: rebase your branch onto the new main (or recreate it from a fresh clone) and open a new PR — feel free to link back to this one for context, and we'll pick up the review there.

Sorry for the churn, and thanks for contributing.