fix(console): support DeepSeek weekend pricing

[opencode-agent]

Summary

• suppress DeepSeek peak rates throughout Saturdays and Sundays in Beijing time
• preserve the existing UTC peak windows on weekdays
• cover weekday window boundaries and weekend behavior

Tests

• bun test test/pricing.test.ts
• bun typecheck
• bun test (12 pass; 2 pre-existing failures in providerUsage.test.ts, where Google output usage is currently 5 but the fixture expects 3)

Requested by: @MrMushrooooom (Jack via Slack)

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

Clean extraction, and the implementation is sound: using a fixed UTC+8 shift is correct here precisely because China has no DST, and getUTCDay() on the shifted date gives the true Beijing weekday. I also checked the midnight-straddle concern — within the two peak windows (UTC 01–04 → Beijing 09–12, UTC 06–10 → Beijing 14–18) the shifted date never crosses into a different calendar day than the UTC date, so there's no boundary case where hour and weekday disagree. The test table covering window start/end plus Sat/Sun/Monday in Beijing is exactly right.

Two points:

1. Holidays. If the provider's peak-pricing notice follows the usual convention of excluding weekends and Chinese public holidays (not just weekends), this suppresses peak only for Sat/Sun and will keep peak rates active during statutory holidays that fall on weekdays. Worth verifying against the exact terms the pricing was derived from — if holidays are excluded too, isPeakPricing needs a holiday table or at least a TODO acknowledging it.

2. Naming nit (packages/console/app/src/routes/zen/util/pricing.ts): the function answers "is this instant inside a weekday peak window", so something like isPeakWindow(date) might describe it more precisely than isPeakPricing. Purely cosmetic.

Also FYI for whoever merges first: this PR and #44306 both touch packages/console/app/src/routes/zen/util/handler.ts, though in different regions (import block + ~line 1049 vs ~line 911), so a trivial rebase may be needed depending on merge order.