CardDAV PROPFIND on /contacts/default returns empty multistatus despite account having contacts

[pauljamesharper]

Summary

PROPFIND requests to the fixed CardDAV collection path (/contacts/default) return a syntactically valid but completely empty <multistatus> response, even when the account has confirmed contacts present (verified directly in Proton's web UI). This affects both collection-level property discovery and Depth:1 listing of address book members.

Environment

• hydroxide installed via go install github.com/emersion/hydroxide/cmd/hydroxide@latest
• Also reproduced identically on acheong08/ferroxide (a fork of this project) — see cross-filed issue there
• Debian 13 (Trixie)
• Account authenticated successfully via hydroxide auth; bridge password confirmed working

Steps to reproduce

1. hydroxide auth user@example.com — succeeds, bridge password generated
2. hydroxide carddav (or ferroxide serve) — starts cleanly, listens on 127.0.0.1:8080
3. Confirm contacts exist in Proton's web UI (Contacts app) — non-zero count
4. Send a PROPFIND directly to the known fixed path:

curl -v -X PROPFIND -u user@example.com \
  -H "Depth: 1" \
  -H "Content-Type: application/xml" \
  --data '<?xml version="1.0"?><propfind xmlns="DAV:"><prop><resourcetype/><getcontenttype/><getetag/></prop></propfind>' \
  "http://127.0.0.1:8080/contacts/default"

Expected

Per RFC 4918/6352, the response should include at minimum one <response> element for the collection itself, plus one <response> per contact at Depth:1.

Actual

HTTP/1.1 207 Multi-Status
Content-Length: 79
Content-Type: text/xml; charset=utf-8

<?xml version="1.0" encoding="UTF-8"?>
<multistatus xmlns="DAV:"></multistatus>

Zero <response> elements, regardless of Depth (0 or 1), regardless of requested props (specific props or <allprop/>), regardless of trailing slash on the URL.

Additional notes

• vdirsyncer's own discovery also fails against this same endpoint with InvalidXMLResponse("Couldn't find home-set."), since current-user-principal and addressbook-home-set PROPFIND queries return the same empty multistatus.
• This matches the symptom in Carddav does not work in thunderbird. #217 ("Found no address books to add for the specified account") and CardDAV in Thunderbird/CardBook #44 (client PROPFIND to .well-known/carddav returning not-found) — but reproduces even when pointed directly at the documented fixed path (/contacts/default), with contacts confirmed present server-side, ruling out both a discovery-layer limitation and an empty-account explanation.
• CalDAV (via the ferroxide fork, which adds calendar support) works correctly with the same account against the same discovery-style flow, suggesting the issue is isolated to the CardDAV listing/PROPFIND handler rather than authentication or the shared HTTP layer.

Happy to provide -debug server-side logs or test further if useful.