Automated tentative appointment creation records success (imip_processed=1, imip_error=0) and permanently retires invitations whose DAV delivery actually failed

Steps to reproduce

1. Nextcloud 33.0.2, Mail 5.10, cron working, "Automatically create
   tentative appointments" enabled (oc_mail_accounts.imip_create = 1).
2. Create any condition under which DAV-side iMIP delivery fails without
   throwing — e.g. enable the server sharing setting "Restrict users to
   only share with users in their groups", which makes principal
   resolution fail in background jobs (no session user; see companion
   issue filed against nextcloud/server).
3. Receive an external iMIP invitation (METHOD:REQUEST, ATTENDEE matches
   the account address exactly) into the synced INBOX.
4. Let IMipMessageJob process it (cron, or occ background-job:execute
   --force-execute).

Expected behavior

If the event cannot be delivered/created, the Mail app should either mark
the message with imip_error and/or retry later, and ideally surface the
failure to the user. A failed delivery should not be recorded as success.

Actual behavior

OCP\Calendar\IManager::handleIMip() returns true even when Sabre delivery
fails (scheduleStatus "3.7;Could not find principal" is logged only at
DEBUG level server-side and never propagated). IMipService::process()
therefore sets imip_processed = true and imip_error = false, and
findIMipMessagesAscending() excludes the message from all future runs —
the invitation is permanently dropped with no event created, no error
flag, no log entry above debug, and no user-visible feedback.

Verified state after processing: oc_mail_messages.imip_message = 1,
imip_processed = 1, imip_error = 0, flag_junk = 0, sent_at < 14 days,
message in synced INBOX (not a special mailbox); no new row in
oc_calendarobjects or oc_schedulingobjects. Manual "Maybe" on the same
invitation works (different code path: browser CalDAV PUT).

Note this is partly a server API limitation (handleIMip cannot signal
delivery failure), but Mail's one-shot semantics amplify it: a transient
server-side condition permanently burns every invitation received while
it persists. Suggested: treat non-created events as retryable, or at
minimum set imip_error so the state is inspectable.

Related: #7750, PR #12144, server PR #56924.

Mail app version

5.10

Nextcloud version

33.0.2

Mailserver or service

No response

Operating system

No response

PHP engine version

None

Nextcloud memory caching

No response

Web server

None

Database

None

Additional info

see also https://github.com/nextcloud/server/issues/63333