fix(imip): don't report success when a calendar cannot process iMip

[kesselb]

Summary

handleIMip() checked IHandleImipMessage only inside the match, so a writable calendar unable to process iMip returned true without doing anything.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[SebastianKrupinski]

The logic here is completely wrong.

// use the primary calendar of the user, otherwise the first one that can process iMip messages
			$primaryCalendar = $this->getPrimaryCalendar($userId);
			$calendar = $primaryCalendar !== null && $this->canHandleImip($primaryCalendar)
				? $primaryCalendar
				: $userCalendars[0];

This assumes that the first user calendar is writable and can handle imip messages. This assumption is completely wrong, as the first calendar can be the "birthday calender" which is read only, this can event be a subscription, also getPrimaryCalendar() already returns the first user calendar when there is no default configured

[tcitworld]

This assumes that the first user calendar is writable and can handle imip messages. This assumption is completely wrong, as the first calendar can be the "birthday calender" which is read only, this can event be a subscription, also getPrimaryCalendar() already returns the first user calendar when there is no default configured

$userCalendars are already filtered above through canHandleImip.

[kesselb]

also getPrimaryCalendar() already returns the first user calendar when there is no default configured

It does not?