Read iCloud subscribed calendars from their source feed

[cosmosified]

Problem

A subscribed iCloud calendar — a webcal feed added to iCloud, such as a
TeamSnap team schedule — appears in the calendar picker and syncs with
success, but always imports zero events. The same calendar shows its
events correctly in Calendar.app.

Root cause

An iCloud subscription is a pointer, not a container of event resources. Its
resourcetype is <cs:subscribed/> and its events live at the URL in the
<cs:source> property (CalendarServer extension).

fetchCalendarEvents() issued a calendar-query REPORT against the collection.
Per RFC 4791 §7.8 that report targets a calendar collection holding event
resources; against a subscription it is accepted but returns an empty
multistatus. The sync therefore recorded success with 0 events and no error,
which made it look like an empty calendar rather than a bug.

parseCalendars() already intentionally lists subscriptions (they advertise
VEVENT), so they were selectable in the picker — only the fetch path was wrong.
The discovery PROPFIND also never requested <cs:source/>, so the feed URL was
never available, even though the cs namespace was already declared.

Changes

All in server/services/appleCalDAV.js:

• Request <cs:source /> during calendar discovery.
• parseCalendars() now reports subscribed and sourceUrl per calendar.
• parseCollectionSource() reads subscription details from a Depth:0 PROPFIND.
• describeCollection() probes a single collection before fetching.
• fetchSubscriptionEvents() reads the upstream ICS feed directly.
• fetchCalendarEvents() branches: subscriptions read their source feed,
  everything else keeps the existing REPORT path unchanged.
• normalizeFeedUrl() rewrites webcal:// / webcals:// to https:// and
  rejects anything not http(s) afterwards.
• Outbound CalDAV request bodies are collected into a frozen
  ICLOUD_XML_MESSAGE class so the wire format lives in one place.
  CALENDAR_QUERY is a builder (a calendar-query must carry a concrete
  time-range); the other four are constants. This is a pure extraction — the
  generated bodies were verified byte-identical to the previously inlined
  literals.

Compatibility and safety

• Existing calendars cannot regress. The subscription probe is wrapped in
  try/catch; any failure logs a warning and falls through to the current REPORT
  path. There is a test for this.
• Credentials are not forwarded. The feed fetch is deliberately
  unauthenticated: the source is a third-party host (TeamSnap, leagues, school
  districts), so the iCloud app-specific password is never sent to it. Tested.
• No SSRF through <cs:source>. Non-http(s) schemes are refused, so a
  malformed or hostile source property cannot trigger a file:// read. Tested.
• Recurrence behaviour is unchanged. icsToEvents() does not expand RRULE,
  and neither did the REPORT path. Left as-is deliberately rather than altered
  as a side effect of this fix.
• No database migration, no schema change, no API change, and no client change.

Testing

cd server && npm test — 196 pass, 0 fail (184 before this branch).

Behavioural tests use a throwaway local http server rather than module mocks,
following the existing approach in homeAssistant.test.js and
outboundTls.test.js; fetchCalendarEvents() takes the collection URL as an
argument, so pointing it at 127.0.0.1 is enough to assert which requests it
makes:

• a subscribed calendar reads its source feed and issues no REPORT
• iCloud credentials are never sent to the feed host
• a regular calendar still uses REPORT and fetches no feed
• a failing probe falls back to REPORT
• a subscription with no source URL fails loudly instead of returning []
• a non-http(s) source is refused rather than fetched
• the REPORT body carries a well-formed calendar-query with a time-range

Request bodies are covered too: each static body is well-formed XML,
CALENDAR_LIST still requests cs:source (dropping it is exactly what made
subscriptions look empty), and the class is frozen.

Unit tests additionally cover webcal:///webcals:// rewriting, http(s)
passthrough, rejection of file:///ftp:///empty, subscription detection, and
parseCalendars() exposing subscribed + sourceUrl.

Verified end to end against a real iCloud-subscribed TeamSnap calendar using
docker-compose-dev.yml: the same source went from success / 0 events to
success / 59 events in 379ms.

Notes for review

• Backend-only, so the light/dark theme and multi-screen-size checks in
  CONTRIBUTING.md do not apply — there are no client changes.
• Applies cleanly on top of 17d2220; a test-merge reports no conflicts.