Use dynamic previous month length for monthly email reports

[officialasishkumar]

Summary

Addresses issue:

• Monthly frequency should be set to previous month days #12385

Relevant technical choices

PHP (Initiator_Task::build_reference_dates): Replaced the hardcoded 30 for FREQUENCY_MONTHLY with (int) $send_date->format( 't' ), which returns the number of days in the month that $send_date falls in. Since the monthly initiator fires on the 1st and $send_date is computed as scheduled_date - 1 day, $send_date is always the last day of the previous month, so format('t') yields the correct count (28, 29, 30, or 31).

JS (FrequencySelector): Updated the monthly period label from "Last 28 days" to "Last month" to reflect the dynamic nature of the reporting window.

Tests (Initiator_TaskTest): Expanded the data_build_reference_dates_uses_expected_period_length data provider to include parameterised test cases for all month-length variants:

• 31-day month (March, triggered April 1)
• 30-day month (June, triggered July 1)
• 28-day month (February 2026, triggered March 1)
• 29-day leap-year month (February 2028, triggered March 1)

The test method signature was updated to accept a timestamp string, allowing each case to use the appropriate boundary date. Snapshot files are updated accordingly.

PR Author Checklist

• My code is tested and passes existing unit tests.
• My code has an appropriate set of unit tests which all pass.
• My code is backward-compatible with WordPress 5.2 and PHP 7.4.
• My code follows the WordPress coding standards.
• My code has proper inline documentation.
• I have added a QA Brief on the issue linked above.
• I have signed the Contributor License Agreement (see https://cla.developers.google.com/).

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Code Reviewer Checklist

• Run the code.
• Ensure the acceptance criteria are satisfied.
• Reassess the implementation with the IB.
• Ensure no unrelated changes are included.
• Ensure CI checks pass.
• Check Storybook where applicable.
• Ensure there is a QA Brief.
• Ensure there are no unexpected significant changes to file sizes.

Merge Reviewer Checklist

• Ensure the PR has the correct target branch.
• Double-check that the PR is okay to be merged.
• Ensure the corresponding issue has a ZenHub release assigned.
• Add a changelog message to the issue.