BUG FIX: Fix month rounding logic when a fixed day is set

[flintfromthebasement]

Summary

Fixes the month-rounding bug in pmprosed_fixDate() where date codes with explicit days (e.g., Y2-M1-01) would incorrectly add an extra month.

The Bug

When using a date code like Y2-M1-01, the "next occurrence" month-rounding logic at line 104 fires even when a fixed day of month (-01) is explicitly set. Since day 01 is almost always less than the current day, the condition $temp_d < $current_d is nearly always true, adding an extra month.

For December, this causes month 13 → January next year, which burns one of the $add_years count and produces completely wrong output (Jan next year instead of Dec next year).

Root Cause

The guard at line 104 only checked 0 == $i (first loop iteration), but didn't check whether a fixed day was explicitly set ($set_d). The rounding is only meaningful when no specific day is given — e.g., M1 without a day component.

The Fix

Add && 0 == $set_d to the condition so the rounding only applies when no explicit day was provided.

Changed:

// Before
if ( 0 == $i ) {

// After
if ( 0 == $i && 0 == $set_d ) {

How to Test

1. Set a level expiration code to Y2-M1-01
2. Sign up on any date other than the 1st of the month
3. Confirm expiration lands on the 1st of the current month + 1 month + 2 years (not +1 extra month)
4. Test with Y1-M0-12 in December — confirm you get December next year, not January

Fixes: #32