Proposal blocker events only consider DTSTART; RDATE occurrences are ignored, causing only the first proposed date to be treated as blocked

After a night of debugging finnally found the root cause with Ai

When creating a meeting proposal with multiple proposed dates, the backend correctly generates a single VEVENT containing all dates via RDATE entries. These appear properly in the calendar UI as multiple tentative occurrences.

However, the blocker‑detection logic only evaluates the event’s DTSTART value and ignores all additional dates stored in RDATE. As a result:

Only the first proposed date is treated as a calendar blocker.

Subsequent proposals do not detect conflicts with the other proposed dates.

The frontend receives only one “blocked” date and displays only that one.

Availability checks and proposal views behave as if the proposal had only a single date.

The blocker event itself is correct — the issue is that the code reading blocker events does not parse RDATE values.

Expected behavior:
All proposed dates (DTSTART + RDATEs) should be treated as individual blocked times when evaluating availability or rendering proposal conflicts.

Actual behavior:
Only the first date (DTSTART) is considered blocked; all RDATE occurrences are ignored.

Root cause:
Blocker‑reading logic uses only DTSTART and does not iterate over RDATE entries.

Fix direction:
Extend blocker detection to extract all occurrences from VEVENTs by reading both DTSTART and all RDATE values.

=> Will try to make a proposal

Start at the blocker-reading logic used by availability checks and proposal conflict rendering, then trace how VEVENT data is converted into blocked times. Verify that DTSTART and every RDATE occurrence are included, and confirm that all proposed dates appear as blocked in the availability and proposal views.