fix(rollup): compute ISO week from UTC calendar fields

[nankingjing]

Problem

toWeekStr() in src/rollup.ts builds the ISO-week label shown in the weekly report title and GitHub issue title (e.g. AI 工具生态周报 2026-W22). It reads the calendar date with local-timezone getters:

const d = new Date(Date.UTC(date.getFullYear(), date.getMonth(), date.getDate()));

Callers pass a CST timestamp (cstDate = now + 8h) whose UTC fields hold the intended CST date — every other date computation in the file and in src/index.ts reads it via toISOString() / getUTC*(). Mixing getFullYear()/getMonth()/getDate() here means the day (and therefore the ISO week/year) shifts whenever the process runs outside UTC.

The weekly workflow even computes the same week independently as date -u +%Y-W%V (UTC) for the commit message, so under a non-UTC timezone the report title and the commit message would disagree.

Fix

Read the calendar date with UTC getters, consistent with the rest of the codebase:

const d = new Date(Date.UTC(date.getUTCFullYear(), date.getUTCMonth(), date.getUTCDate()));

This is a no-op when the process runs in UTC (current CI), and produces the correct, stable ISO week everywhere else.

Verification

Reproduction with the exact function flow (cstDate = now + 8h):

now (UTC)	saved file date	before (local getters)	after (UTC getters)
2026-01-04T19:00Z	2026-01-05	2026-W01 ❌	2026-W02 ✅
2026-05-24T20:00Z	2026-05-25	2026-W21 ❌	2026-W22 ✅
2026-12-27T19:00Z	2026-12-28	2026-W52 ❌	2026-W53 ✅

(run under TZ=PST8PDT; under TZ=UTC both columns match, confirming no regression). The "after" column matches an independent ISO-week reference.

Ran against the repo with the change applied: pnpm typecheck, pnpm lint, and pnpm format:check all pass.

[nankingjing]

Reviewed — using UTC getters avoids date shift when the process runs outside CST, a clean timezone fix. Ready for review.