fix: list contacts on servers that reject a bare prop-filter - #3

fetchVCards discovers the card hrefs with an addressbook-query whose default
filter is a condition-less <prop-filter name="FN"/>. RFC 6352 reads that as
"every card carrying an FN property", but Open-Xchange answers it with an
empty result. The collection then looks empty, the multi-get stage never
runs, and list-contacts reports zero contacts for a populated address book.
mailbox.org is one affected host.

Discover the hrefs with a PROPFIND and hand them to fetchVCards as
objectUrls, which routes the fetch through addressbook-multiget and skips the
filter entirely. PROPFIND is mandatory for a CardDAV collection, so this
works everywhere; resolve-contact already takes the same objectUrls path,
which is why get-contact kept working while list-contacts did not.

PROPFIND returns the collection itself alongside its members, and that entry
was recognised by comparing paths for exact equality. Servers differ on
whether they put a trailing slash there, and it need not match the one the
caller passed in, so the collection could survive into the href list and be
requested as if it were a card. Harmless downstream, since a response without
vCard data is filtered out anyway, but it defeats the empty-collection short
circuit and it is the same trailing-slash fragility that hrefFor already
guards against elsewhere in this repo.