fix(imap4): accept SORT data when server returns tagged NO

[bakgaard]

Summary

• Dovecot may return valid SORT results in an untagged * SORT response but then send a tagged NO (e.g. "Requested sort would have taken too long")
• The sort data is still complete and usable — Dovecot delivers all UIDs before rejecting the command
• Previously, normalizeSortResponse relied solely on the tagged response status, discarding perfectly good sort data
• This caused SOGo's mail view to fail with could not sort contents of URL on large mailboxes (2000+ messages) served by Dovecot instances with aggressive sort-time policies

Fix

If sort data was received in the untagged response, promote the result to success regardless of the tagged status. This is a minimal, safe change — it only affects the SORT normalizer and only when data was actually returned.

Reproduction

1. Configure SOGo with a Dovecot IMAP server that has mail_sort_max_time or similar policy limits
2. Have a mailbox with 2000+ messages
3. Open the mail tab — SOGo sends UID SORT (REVERSE ARRIVAL) UTF-8 NOT DELETED
4. Dovecot returns * SORT <all UIDs> followed by tagged NO Requested sort would have taken too long
5. SOGo fails to display the mailbox

Test plan

• Verify mail tab loads on large mailboxes with Dovecot
• Verify normal SORT (tagged OK) still works
• Verify SORT with no data + tagged NO still returns failure

🤖 Generated with Claude Code

[bakgaard]

Issue found with 2338 mails in inbox. This made it work