Fix CalDAV/CardDAV multiget loading entire collections into memory

A REPORT multiget for a handful of resources previously listed the
whole calendar/address book (every row incl. ical_data/vcard) and
filtered by href in Rust with an O(N×M) substring scan. Large
collections paid full-table latency, RAM and DB CPU on every sync.

- Add find_events_by_ical_uids / get_contacts_by_uids through every
  layer (domain repo trait → PG repo → storage port/adapter → use case
  → handler) using one indexed `= ANY($2)` query, mirroring the
  existing single-UID lookups.
- Extract UIDs from multiget hrefs with a shared, tested
  uid_from_multiget_href helper (percent-decoding, case-insensitive
  extension strip, collection hrefs rejected). Exact UID matching also
  removes the false positives the old substring filter allowed.
- CalDAV PROPFIND single-event path now uses the existing indexed
  get_event_by_ical_uid instead of listing all events.
- Honour the already-documented limit/offset query params on
  GET /api/address-books/{id}/contacts: optional ListQuery fields
  thread through ContactUseCase::list_contacts to a paginated repo
  query. Omitted params keep returning the full book (frontend and
  DAV listing/sync paths unchanged).

https://claude.ai/code/session_0193Hff42gaA962wThxMGSd1

src/application/ports/calendar_ports.rs

@@ -95,6 +95,14 @@ pub trait CalendarStoragePort: Send + Sync + 'static {
         calendar_id: &str,
         ical_uid: &str,
     ) -> Result<Option<CalendarEventDto>, DomainError>;
+    /// Indexed batch lookup by iCalendar UID (`ical_uid = ANY(...)`) — the
+    /// CalDAV multiget REPORT must use this instead of listing the whole
+    /// calendar (every row + its `ical_data`) and filtering client-side.
+    async fn find_events_by_ical_uids(
+        &self,
+        calendar_id: &str,
+        ical_uids: &[String],
+    ) -> Result<Vec<CalendarEventDto>, DomainError>;
     async fn list_events_by_calendar(
         &self,
         calendar_id: &str,
@@ -197,6 +205,15 @@ pub trait CalendarUseCase: Send + Sync + 'static {
         ical_uid: &str,
         user_id: Uuid,
     ) -> Result<Option<CalendarEventDto>, DomainError>;
+    /// Resolve a batch of events by their iCalendar UIDs with a single
+    /// indexed query. UIDs without a matching event are silently absent
+    /// from the result (CalDAV multiget semantics).
+    async fn get_events_by_ical_uids(
+        &self,
+        calendar_id: &str,
+        ical_uids: &[String],
+        user_id: Uuid,
+    ) -> Result<Vec<CalendarEventDto>, DomainError>;
     async fn list_events(
         &self,
         calendar_id: &str,

src/application/ports/carddav_ports.rs

@@ -82,9 +82,25 @@ pub trait ContactUseCase: Send + Sync + 'static {
         uid: &str,
         user_id: Uuid,
     ) -> Result<Option<ContactDto>, DomainError>;
+    /// Resolve a batch of contacts by their vCard UIDs with a single
+    /// indexed query (`uid = ANY(...)`) — the CardDAV multiget REPORT
+    /// must use this instead of listing the whole address book and
+    /// filtering client-side. UIDs without a matching contact are
+    /// silently absent from the result.
+    async fn get_contacts_by_uids(
+        &self,
+        address_book_id: &str,
+        uids: &[String],
+        user_id: Uuid,
+    ) -> Result<Vec<ContactDto>, DomainError>;
+    /// List contacts in an address book. `limit`/`offset` bound the
+    /// result for paginated callers (REST API); `None` returns the full
+    /// book, which the CardDAV listing/sync paths rely on.
     async fn list_contacts(
         &self,
         address_book_id: &str,
+        limit: Option<i64>,
+        offset: Option<i64>,
         user_id: Uuid,
     ) -> Result<Vec<ContactDto>, DomainError>;
     async fn search_contacts(