fix(schedule): Date rules silently ignored due to zero-padding mismatch in Day::Display

[vit0-9]

Bug description**

Date-variant ScheduleRules set via the API are silently ignored during Schedule::freebusy, causing the schedule to fall back to the matching WDay rule as if no date override existed.

Root cause

Schedule::freebusy builds a date_lookup HashMap using the raw string value stored inside the ScheduleRuleVariant::Date variant (e.g. "2026-04-02"), then looks up each day using day_cursor.to_string(). The Day::Display implementation formats without zero-padding:

// Day { year: 2026, month: 4, day: 2 }.to_string() → "2026-4-2"
// but the rule stored via the API contains → "2026-04-02"
// HashMap lookup: "2026-4-2" != "2026-04-02" → no match → WDay fallback

Any client that sends ISO-8601 dates (which is the standard and what the TypeScript client does) will silently get no date override applied. This includes both blocking dates (intervals: []) and date-specific custom hours.

Fix

Two minimal changes:

1. Day::Display — zero-pad month and day to produce ISO-8601 compatible strings, making the format consistent everywhere:

// Before: write!(f, "{}-{}-{}", self.year, self.month, self.day)
// After:
write!(f, "{}-{:02}-{:02}", self.year, self.month, self.day)

2. Schedule::freebusy — normalize date keys through Day's parser before inserting into date_lookup, so lookups are robust regardless of the input format:

ScheduleRuleVariant::Date(datestr) => {
    let normalized = match datestr.parse::<Day>() {
        Ok(day) => day.to_string(),
        Err(_) => datestr.clone(),
    };
    date_lookup.insert(normalized, &rule.intervals);
}

Fix 2 makes the lookup defensive against any future format variation. Fix 1 ensures the canonical output of Day is proper ISO-8601 from here on.

[GuillaumeDecMeetsMore]

Hello @vit0-9, thank you for the PR !

Looks good to me, good catch 👍
Could you fix the formatting issue? Once that’s done, I’ll merge and deploy a new version