fix(common): honor DeepSeek Beijing weekend boundaries

[c8dhjp4tyv-bit]

Recreated on the rewritten main after #1096 was auto-closed during repository maintenance. This carries the final change set from the old branch onto the new history.

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

Prior validation before the history rewrite:

• 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.

[codebuff-team]

The core fix is sound: previously isBeijingWeekend applied off-peak treatment unconditionally, which would retroactively assume the weekend rule applied even before DeepSeek's own effective date. Gating it behind DEEPSEEK_WEEKEND_OFFPEAK_EFFECTIVE_AT_UTC and testing both sides of that boundary (2026-08-22T09:59:59Z vs 2026-08-23T01:30:00Z) is the right way to pin this kind of vendor-timing bug, and the added test cases for the Friday/Sunday UTC boundary (2026-08-28T15:00:00Z etc.) correctly exercise the case the PR describes — where the old suite happened to only use instants where UTC and Beijing agreed.

The doc comments in freebuff-peak-hours.ts are a good addition: explaining why Beijing's fixed UTC+8 offset (no DST since 1991) is safe to hard-code, and why the effective date is stored as an instant rather than a local date, both show real care about time-zone correctness.

One nit: the diff also silently deletes two unrelated explanatory comments in the test file (around 'The whole bug in one assertion' and the timeZone: undefined note). These aren't harmful but they're not part of this PR's stated scope, and removing useful context in an unrelated test is the kind of thing a reviewer will ask about. Consider keeping them or explaining the removal in the PR body.

I can't verify the specific vendor announcement date against #1090 from this vantage point, so I'd want a maintainer to confirm the 2026-08-22T16:00:00Z timestamp against the actual DeepSeek notice before merging, but the code structure, tests, and reasoning are solid enough to be worth porting.

[c8dhjp4tyv-bit]

Addressed both review points. I restored the two unrelated explanatory timezone-test comments that had been dropped during reconstruction. I also independently rechecked the effective instant: the published rule is effective at 00:00 Beijing Time on Sunday 2026-08-23, which is exactly 2026-08-22T16:00:00Z (UTC+8). This is independently corroborated by the Aug 22 contemporaneous report (https://www.odaily.com.cn/en/newsflash/511930) and an archived-doc comparison that explicitly gives the UTC conversion (https://aitoolsworth.com/deepseek-weekend-off-peak-pricing/). Targeted peak-hours suite: 31 passed, 0 failed.