test(common): pin the Beijing weekend shift with edge instants

[rekty]

{
"title": "test(common): pin the Beijing weekend shift with edge instants",
"head": "rekty:fix/pin-beijing-weekend-shift-tests",
"base": "main",
"body": "Closes #1090\n\n## Problem\n\nBoth weekend tests sit at 02:00Z, inside the band where the +8h Beijing shift and a plain getUTCDay() agree. Deleting the shift leaves deepseekPricingWindow returning identical answers for all 168 hours of a week — the suite stays green, and the file only starts lying the day DeepSeek moves a window past 16:00Z.\n\n## Fix\n\n1. Export isBeijingWeekend from freebuff-peak-hours.ts (doc-comment explains why: the weekend band Fri 16:00Z → Sun 16:00Z never overlaps the peak windows, so only the predicate can pin the shift directly).\n2. Add four edge-pinning tests at the exact instants where the two calendars disagree:\n\n| instant | Beijing | weekend |\n|---|---|---|\n| 2026-08-28T15:00:00Z | Fri 23:00 | no |\n| 2026-08-28T16:00:00Z | Sat 00:00 | yes |\n| 2026-08-30T15:00:00Z | Sun 23:00 | yes |\n| 2026-08-30T16:00:00Z | Mon 00:00 | no |\n\n## Verification\n\n- All 24 tests in the file pass with the fix in place.\n- Mutation check: removing the + 8 * 60 * 60 * 1000 shift makes exactly the two boundary tests fail (16:00Z Friday and 16:00Z Sunday), confirming the suite now catches the regression.\n"
}

[codebuff-team]

Good catch. The existing weekend tests at 02:00Z sit inside the band where the Beijing shift and a naive getUTCDay() agree, so deleting the +8h offset wouldn't fail anything — this PR closes that hole.

The math checks out: 2026-08-28T15:00Z (Fri 23:00 Beijing, weekday) vs 16:00Z (Sat 00:00 Beijing, weekend), and the symmetric Sunday/Monday pair. These are exactly the four instants where a plain UTC day-of-week and the shifted one diverge, so the test can only pass if the +8 * 60 * 60 * 1000 offset is present and correct.

Exporting isBeijingWeekend for testability is a reasonable, minimal change, and the doc comment explains why the exported predicate is necessary rather than just testing the public deepseekPricingWindow/isDeepSeekExpensiveWindow functions indirectly (the weekend band never overlaps a peak window, so those functions can't see the shift at all).

Small, focused, in scope (common/src), verified against a mutation (removing the shift breaks exactly the two boundary cases per the PR description). Worth porting as-is.