[Bug] fix: off-by-one date calculation error due to UTC timezone mismatch

[praaatap]

Bug Description

The application frequently needs to format dates as YYYY-MM-DD (e.g., getting the date for "yesterday", "today", or computing date ranges). It relies heavily on date.toISOString().split('T')[0]. Because toISOString() always returns the UTC representation of the date, users in timezones far from UTC (like Japan, Australia, or the US West Coast) may receive the incorrect date depending on the time of day. This results in the Scrum report querying the wrong date range from the APIs.

Steps to Reproduce

Steps to reproduce the behavior:

1. Set your system timezone to a region far ahead of or behind UTC (e.g., Asia/Tokyo UTC+9 or America/Los_Angeles UTC-8).
2. Open the Scrum Helper extension early in your morning (if UTC+) or late at your night (if UTC-).
3. Select the "Previous Day" option or set a date range ending "today".
4. Generate the report.
5. See error: The generated report fetches data for the previous UTC day rather than your actual local "today" or "yesterday".

Expected Behavior

The extension should calculate "today" and "yesterday" using the user's local timezone, so the fetched commits and PRs accurately reflect the user's local days.

Actual Behavior

The extension calculates dates using toISOString(), which forces the local date into UTC. If the local date does not match the UTC date at the time of report generation, the report queries the wrong 24-hour period.

Screenshots

N/A - This is an underlying logic and API query issue.

Additional Context

This bug occurs at least 15 times across the codebase, specifically in src/scripts/scrumHelper.js, src/scripts/popup.js, and src/scripts/main.js. Replacing toISOString().split('T')[0] with a local date string formatter (e.g., manually combining getFullYear(), getMonth(), and getDate()) resolves this.

---

Contribution Checklist

• I have searched existing issues to ensure this bug hasn't been reported
• I have provided clear reproduction steps
• I have included relevant environment details
• I have described both expected and actual behavior