Zimbra: changes() can return objects deleted mid-sync, since _fetch_many still uses calendar-multiget #48

Disclaimer: AI-generated text below the line, generated by Claude Opus 5.5, from the prompt:

merge #46 as for now [found by the clean-context review of that merge, and filed rather than fixed]

#46 made get() and get_by_native_id() read with a plain GET where caldav's multiget.deleted hint says the server's calendar-multiget returns deleted objects (Zimbra). _fetch_many() (src/calendaring/_async/caldav.py), which changes() uses, still goes through multiget. So on Zimbra, an object deleted between changes() listing its href and fetching it comes back with its old data, while the base class promises that "objects gone meanwhile are left out".

The window is narrow and only Zimbra has the problem, but news/+caldav-values.bugfix.rst ("an object is read with a GET") reads as if every read were covered.

Fix: on such servers, _fetch_many() does a GET per href, with a test that monkeypatches multiget the way test_caldav_backend.py's multiget-ghost test does. If the fix misses the release, narrow the news fragment instead.