fix(encounters): the visit list carries its links

Two defects behind one omission. The card counts what a visit produced, so a
list that dropped the links made every card read zero for a visit with three
documents. And the edit sheet seeds its pickers from the row it was handed: an
edit opened from a linkless list row would save a replace-set of three empty
arrays and silently unfile everything the visit had collected.

The links now ride the list, resolved in three grouped queries for the whole
page through the batched arm of the same service the detail uses, with the same
per-family redaction from the same predicate. The single-visit read hook had no
caller and is gone with it — the list is where the surfaces read from.

Both defects get a test that would have caught them: the card counts assert
against a populated links object, the draft asserts the arrays survive a round
trip through draftToBody, and the integration file asserts the list response
itself carries every family.

docs/api/openapi.yaml

@@ -34915,8 +34915,10 @@ components:
         - labResults
         - conditions
       additionalProperties: false
-      description: The three link families of one visit, each ordered by when it was filed. Present on the detail response,
-        absent from the list.
+      description: "The three link families of one visit, each ordered by when it was filed. Present on BOTH the list and the
+        detail: a card shows counts of what the visit produced, and an edit opened from a list row seeds its pickers
+        from that row — a list without them would make the first read zero and the second unfile everything on save. The
+        list resolves them in three grouped queries for the whole page, not three per row."
     EncounterLinkedTarget:
       type: object
       properties: