[Pascal-ZeGerman]

Summary

Fix: iCloud CalDAV cross-host calendar sharding (3.3.0-rc2)

Every CalDAV write from the asp_parking integration to iCloud has been failing
since at least 2026-07-25 (19/19 attempts in the prior 7 days, 0 successes),
with:

ValueError: https://caldav.icloud.com/ can't be joined with
https://p117-caldav.icloud.com:443/278773852/calendars/.../

Root cause: iCloud shards each account's actual calendar data onto a
per-account host (e.g. p117-caldav.icloud.com) that differs from the
generic login entry point (caldav.icloud.com) the CalDAV client connects
with. caldav_sync._get_calendar() reconnected with the generic host and
called principal.calendar(cal_url=...), whose caldav 2.1.0 implementation
does a purely local URL.join() (caldav/lib/url.py) that raises
ValueError whenever the client's host and the target URL's host differ —
which is always true for iCloud accounts.

Changes

custom_components/asp_parking/caldav_sync.py

_get_calendar() still tries the cheap local principal.calendar(cal_url=...)
join first (no extra network round-trip — correct for same-host servers like
Radicale/Nextcloud/Baikal). On the specific cross-host ValueError, it now
falls back to principal.calendars() — a real network request that follows
iCloud's redirect to the correct sharded host — and matches the target
calendar by URL path, which stays stable even if iCloud rebalances the
shard in the future. Raises a clear CalDAVWriteError if the fallback also
finds no match, instead of the previous opaque ValueError.

tests/test_caldav_sync.py

Added 3 tests reproducing the exact production failure:

• cross-host ValueError → fallback finds the matching calendar by path
• cross-host ValueError → no path match → raises CalDAVWriteError
• same-host regression guard: the fast local-join path never pays the extra
  principal.calendars() network round-trip

custom_components/asp_parking/manifest.json

Version bump 3.3.0-rc1 → 3.3.0-rc2.

Verification

• New unit tests pass (3/3), reproducing the exact ValueError from
  production logs before the fix, passing after.
• Full CalDAV test suite: 124/124 passed, no regressions.
• Full project test suite: 988 passed (6 pre-existing, unrelated
  test_sign_retrieval.py failures confirmed via git stash to predate
  this change — network-sandboxed test environment issue).
• Live verification against production iCloud account: ran
  write_or_update_event → _get_calendar → delete_event end-to-end
  inside the running Home_Assistant container with the real stored
  credentials and the real caldav_url/caldav_calendar pair that was
  previously failing. Write and cleanup both succeeded
  (WRITE_RESULT=OK uid_match=True, CLEANUP_RESULT=OK).
• Deployed to the live container (docker cp + restart); confirmed
  asp_parking loads cleanly post-restart with zero CalDAV write failed warnings.

Key Decisions

• Kept the cheap local principal.calendar(cal_url=...) join as the fast
  path rather than switching entirely to principal.calendars() matching,
  to avoid an extra network round-trip for the common self-hosted CalDAV
  case and to avoid touching the large existing test surface that mocks
  principal.calendar directly.
• Matched by URL path (not full URL) in the fallback so the fix also
  survives a future iCloud shard rebalance that changes the hostname again.