fix(cli-date): reject month/day overflow in parseLocalDate

[lfl1337]

Summary

Follow-up to #80, which introduced parseLocalDate. The regex-only
validation there accepts structurally valid but semantically invalid
dates like 2026-13-45 or 2026-02-30. The Date constructor
silently rolls them forward into a different valid date, so --from /
--to then produce a misleading "must not be after" error instead
of rejecting the input.

Fix

After constructing the Date, compare the round-tripped
year / month / day back to the parsed numbers. If they diverge,
throw a clear "month or day out of range" error.

Before

$ codeburn report --from 2026-13-45
Error: --from must not be after --to (got 2026-13-45 > undefined)

After

$ codeburn report --from 2026-13-45
Error: Invalid date "2026-13-45": month or day out of range

$ codeburn report --from 2026-02-30
Error: Invalid date "2026-02-30": month or day out of range

Tests

Two new cases in tests/date-range-filter.test.ts cover month and day
overflow. Full file 10/10 green.

[github-actions]

firstlook

Signal	Detail
Account	Created 5y 1mo ago	✅
Repos	8 public	✅
Profile	None provided	⚠️
History	3 merged, 0 rejected elsewhere	✅
Merge quality	1 unique mergers, 1 repos with 100+ stars	✅
Activity	2/12 months active	⚠️
Followers	1	⚠️
Signed	No	⚠️

⚠️ Dormant Reactivation -- Active 2/12 months despite 5y account

Review Suggested (score: 39/100) -- Limited history or new account. Review with extra care.

Details

• Self-merged: 3 | Externally merged: 5
• Contributed to 1 repos with 100+ stars
• This repo: 5 merged, 2 closed

_firstlook

[Qodo-Free-For-OSS]

Hi, parseLocalDate now rejects inputs where Date round-tripping changes the parsed year, but JavaScript interprets years 0–99 as 1900–1999. Dates like "0099-01-01" will incorrectly throw "month or day out of range" despite matching the YYYY-MM-DD format contract.

Severity: action required | Category: correctness

How to fix: Handle years 0–99 explicitly

Agent prompt to fix - you can give this to your LLM of choice:

Issue description

parseLocalDate round-trip validation breaks for years 0000–0099 because new Date(y, m-1, d) interprets numeric years 0–99 as 1900–1999.

Issue Context

The regex allows any 4-digit year, so users can pass 0099-01-01. With the current check, these will throw month or day out of range even when month/day are valid.

Fix Focus Areas

• src/cli-date.ts[10-20]

Suggested fix approach

• Construct the date in a way that preserves years 0–99 (e.g., create new Date(0) then call setFullYear(y, m-1, d) and zero the time), then apply the same round-trip validation.
  • Example:
    • const parsed = new Date(0); parsed.setFullYear(y, m-1, d); parsed.setHours(0,0,0,0);
• Alternatively, explicitly disallow years 0000–0099 with a clear error message if you don’t want to support them, but then also update the user-facing contract/docs/tests accordingly.

---

Found by Qodo code review. FYI, Qodo is free for open-source.