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.

[xyzs996]

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.