#11178: fix: use Number.parseInt with explicit radix in parseDateToMs

## Summary - `parseDateToMs` in `usage.ts` uses bare `parseInt(year)` without radix, inconsistent with the rest of the codebase where all other `parseInt` calls use `Number.parseInt(x, 10)` - Replace with `Number.parseInt(year, 10)` for consistency and to avoid potential issues with leading-zero strings being interpreted as octal in older engines ## Test plan - [x] All 5 usage handler tests pass - [x] Verified all other parseInt calls in src/ already use explicit radix Generated with [Claude Code](https://claude.com/claude-code) <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates `parseDateToMs` in `src/gateway/server-methods/usage.ts` to use `Number.parseInt(..., 10)` instead of bare `parseInt(...)` when converting `YYYY-MM-DD` capture groups into numbers for `Date.UTC(...)`. The change aligns this function with the codebase’s apparent convention of always supplying an explicit radix for `parseInt`, and avoids legacy leading-zero/octal parsing edge cases while keeping the date parsing/UTC semantics unchanged. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk. - The change is a small, localized refactor that only adds an explicit radix to integer parsing in `parseDateToMs` without altering control flow or the date validation regex; no behavioral regressions are apparent from the diff. - No files require special attention <!-- greptile_other_comments_section --> <!-- /greptile_comment -->