fix(contacts): do not let one broken contact blank the whole app

[MiMoHo]

Summary

A single contact with one malformed property could take down the entire web UI, leaving the user with "no address books" and no way to recover from within the app. This PR fortifies the contact loading pipeline so that one broken contact can, at worst, only affect itself.

Failure mechanism (as diagnosed in #5149 and #5250)

1. ical.js getters on Contact can throw for malformed/exotic property values. Two confirmed classes:
   • value-typed UID properties (e.g. UID;VALUE=DATE-TIME:…, diagnosed by @seblu in Parse errors in a contact make the entire app UI fail and show no contacts at all #5149): getFirstPropertyValue() returns a parsed object instead of a string, and its stringification inside the key getter can throw,
   • compact REV:20230911 as written by Thunderbird CardBook or DAVx5 (Contacts web app unusable, possible after adding a contact with a not expected date field — TypeError: can't access property "getAllSubcomponents", this.component is null in sortContacts #5250): with ical.js 2.2.1, even getFirstPropertyValue('rev') itself throws Error: invalid date-time value: "2023-09-11T::" (reproducible with a plain node script against the bundled ical.js).
2. The throw happens inside the sortContacts mutation, which iterates all contacts of all address books.
3. The exception propagates into the .catch() of getContactsFromAddressBook, which was written for DAV fetch errors and responds by deleting the address book from the store.
4. Because sortContacts is global, the same broken contact makes the commit fail for every address book being loaded → all address books get removed from the store → the app shows no address books and no contacts at all, and even the settings for deleting/disabling the offending address book become unreachable.

Changes

• Contact.uid now reads the raw jCal value (always a plain string) instead of the parsed value object, so uid/key access never throws. Identity access must be infallible — key is used as store index everywhere.
• The sortContacts mutation skips (and logs) contacts whose property getters throw, instead of failing the whole list.
• getContactsFromAddressBook only removes the address book from the store when the DAV fetch itself fails. If processing the successfully fetched contacts fails, the address book stays visible and an error toast is shown — the data on the server is fine.

Relationship to other work

Complementary to #5265, which makes the last modified sort order actually work with malformed REV values (numeric sort keys read from raw jCal). This PR is about containment: no single contact may blank the app, whatever the sort order. Together they fully cover #5250.

Checklist

• Jest tests added:
  • uid/key robustness for the exact vCard diagnosed in Parse errors in a contact make the entire app UI fail and show no contacts at all #5149
  • sortContacts with a real REV:20230911 contact (Contacts web app unusable, possible after adding a contact with a not expected date field — TypeError: can't access property "getAllSubcomponents", this.component is null in sortContacts #5250 scenario): list survives, broken contact skipped; with a sort key that does not touch the broken property, the contact stays listed
  • getContactsFromAddressBook: address book removed on fetch failure, kept on processing failure, unparseable vCards skipped with toast
• Full Jest suite passes (23 tests), npm run lint clean for the touched files (0 errors), production build succeeds

Resolve #5149
Helps with #5250 (together with #5265)

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 97.36842% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/models/contact.js	75.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!