docs(search): document in-memory sort tradeoff and total=size() limitation

Add TODO comment explaining why SENDER/RECEIVER sort is in-memory
(JPA INNER JOIN drops null-sender docs) and note that pagination
will require a DB COUNT query in DocumentSearchResult.of().

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

backend/src/main/java/org/raddatz/familienarchiv/dto/DocumentSearchResult.java

@@ -5,6 +5,11 @@ import org.raddatz.familienarchiv.model.Document;
 import java.util.List;
 
 public record DocumentSearchResult(List<Document> documents, long total) {
+    /**
+     * Creates a result where total equals the list size.
+     * No pagination yet — the full matched set is always returned.
+     * When pagination is added, total must come from a DB COUNT query, not list.size().
+     */
     public static DocumentSearchResult of(List<Document> documents) {
         return new DocumentSearchResult(documents, documents.size());
     }

backend/src/main/java/org/raddatz/familienarchiv/service/DocumentService.java

@@ -292,6 +292,9 @@ public class DocumentService {
                 .and(hasTagPartial(tagQ))
                 .and(hasStatus(status));
 
+        // SENDER and RECEIVER are sorted in-memory because JPA's Sort.by("sender.lastName")
+        // generates an INNER JOIN that silently drops documents with null sender/receivers.
+        // TODO: replace with a native @Query using ORDER BY ... NULLS LAST when pagination is added.
         if (sort == DocumentSort.RECEIVER) {
             List<Document> results = documentRepository.findAll(spec);
             return sortByFirstReceiver(results, dir);